Upload
dinhthuy
View
212
Download
0
Embed Size (px)
Citation preview
THÈSE
Présentée devant
L’Institut National des Sciences Appliquées de Lyon
Pour obtenir
LE GRADE DE DOCTEUR
Spécialité : INFORMATIQUE
ÉCOLE DOCTORALE : École Doctorale Informatique Information et Société
Par
MMAAYYYYAADD JJAABBEERR
Ingénieur en informatique
Titre :
Architecture de Système d’Information Distribué pour la Gestion de
la Chaîne Logistique :
Une Approche Orientée Services
Soutenance 09 février 2009
Jury
Valérie ISSARNY Directeur de recherches, INRIA – Paris Rapporteur
Hervé PINGAUD
Professeur, École des Mines d’Albi-Carmaux Rapporteur
Dominique RIEU Professeur, Laboratoire LIG – IMAG, Saint Martin
d’Hères
Examinateur
Youakim BADR Maître de Conférences, LIESP – INSA de Lyon Examinateur
Frédérique BIENNIER Professeur, LIESP – INSA de Lyon Directeur de thèse
Laboratoire d’Informatique pour l’Entreprise et les Systèmes de Production LIESP
Lyon, France
RESUMÉ
Afin d’améliorer leur compétitivité, les entreprises cherchent à réduire le
coût de leurs processus métiers, et à augmenter leur capacité de
développement rapide pour des nouveaux services et produits. Pour cela, les
entreprises se concentrent de plus en plus sur leur cœur de métier alors
qu’elles sont de plus en plus impliquées dans des collaborations avec leur
environnement. Cette tendance implique le renforcement des relations de
collaboration avec des partenaires, menant aux organisations virtuelles. Ces
organisations interentreprises doivent payer une attention particulière sur les
opérations logistiques, de l’approvisionnement à la distribution des produits
finaux. L’amélioration de la performance globale d’une telle chaîne
logistique repose sur l’optimisation du processus industriel mais aussi sur
un processus efficace de coordination et de partage de l’information entre
les partenaires. La mise en œuvre du processus de la chaîne logistique
repose largement sur les technologies de l’information et de la
communication. Ils conduisent à dépasser les frontières des entreprises et
ensuite à créer de nouvelles occasions de business.
L’idée de cœur de notre approche repose sur une vision globale
de collaboration flexible entre les partenaires de la chaîne logistique. Cela
est réalisé par le biais d’un cadre global fondé sur des technologies et des
normes neutres pour supporter la gestion de collaboration. Dans ce travail,
nous présentons un cadre intégré pour la collaboration interentreprises. Le
principe du cadre est basé sur la facilitation de l’accès aux processus des
systèmes patrimoniaux et la définition des processus métiers communs par
l’assemblage de services distribués sous forme d’un Workflow global.
L’engagement potentiel de plusieurs systèmes patrimoniaux hétérogènes
dans un processus commun collaboratif est associé à plus forte exigence
d’interopérabilité pour l’organisation de processus métiers et pour l’échange
d’informations. Ces contraintes imposent une infrastructure flexible au
niveau de systèmes d’information et de systèmes de communication.
En outre, le cadre gère les transactions. Il propose notamment une
gestion de ressources et de transactions distribuées afin d’orchestrer des
services lâchement couplés dans des unités interconnectées et de garantir
une exécution correcte et fiable pour le processus commun. Ainsi, les
définitions nécessaires et les algorithmes qui peuvent maintenir
constamment les ressources partagées sont fournis offrant un processus
cohérent au travers de multiples systèmes d’information autonomes et de
systèmes de Workflow locaux de partenaires.
Mots clés :
Chaîne logistique; Collaboration interentreprises; processus métier;
Architecture orientée service; Workflow; Transactions distribuées.
Mayyad JABER iv
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
ABSTRACT
In order to improve their competitiveness, many enterprises seek to
reduce the cost of doing business, and advance their capability for
rapidly developing new services and products. For that, enterprises
focus more and more on their core business while they are more and
more involved in collaborative organizations. This trend involves
reinforcing collaboration relationship with partners leading to virtual
organizations. Such inter-enterprises organizations have to pay a
particular attention on logistic operations, from procurement to final
products distribution. Improving the global performance of such a
supply chain relies on both industrial optimization and on an efficient
process coordination and information sharing between partners . The
enactment of supply chain business process relies heavily on
information and communication technologies (ICT). They lead to
overcome boarders between enterprises and then create new business
opportunities.
The core idea of our approach hinges on a global vision for
flexible collaboration of supply chain partners and provides a global
framework based on neutral technologies and standards to support
collaboration management. In this work, we present an open integrated
framework to support inter-enterprises collaboration based on
facilitating the access to private processes of legacy systems and
defining common business process issued from assembling distributed
services through a global workflow. Potential involvement of several
legacy heterogeneous systems in one collaborative business process is
coupled with stronger interoperability requirements both for Business
Process organization and information exchange. These constraints lead
to lean reconfigurable infrastructure including information and
communication systems.
In addition, the framework manages transactions processes. It
particularly develops a distributed transactional management support in
order to orchestrate loosely coupled services into cohesive units of work
and guarantee consistent and reliable execution. Thus, the necessary
definitions and algorithms that can consistently maintain shared
resources are provided offering coherent processes spanning multiple
autonomous information systems and local workflows of partners.
Key-words:
Supply chain; Inter-enterprise collaboration; Business Process; Service
Oriented Architecture; Workflow; Distributed transactions.
Mayyad JABER v
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
REMERCIMENT
Mes remerciements vont tout d’abord à Madame BIENNIER, Professeur
enseignant au département Informatique de l’INSA de Lyon, pour son
soutien et le temps qu’elle m’a accordé tout au long de ce travail.
Mes remerciements vont également à :
Madame Valérie ISSARNY, directrice de Recherche à l’INRIA
ROCQUENCOURT, d’avoir accepté de rapporter mon mémoire de thèse
et d’avoir accepté de participer au jury.
Monsieur Hervé PINGAUD, professeur au centre de Génie
Industriel de l’Ecole des Mines d’Albi-Carmaux, d’avoir accepté de
rapporter mon mémoire de thèse et d’avoir accepté de participer au jury.
Madame Dominique RIEU, professeur à l’IUT2 de Grenoble,
d’avoir accepté de participer au jury.
Monsieur Youakim BADR, maître de Conférences à l’INSA de
Lyon, d’avoir accepté de participer au jury.
Mayyad JABER vi
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Table de matières
Chapitre 1 Introduction générale ------------------------------------------------------ 1
Chapitre 2 Contexte ---------------------------------------------------------------------- 5 2.1 Introduction ------------------------------------------------------------------------------------ 5
2.1.1 Notions de base de la chaîne logistique ------------------------------------------------- 7 2.1.1.1 La valeur : Le moteur qui conduit la Chaîne Logistique ----------------------- 7 2.1.1.2 La source de valeur et la nature de la chaîne logistique ------------------------ 8 2.1.1.3 L’opération virtuelle ---------------------------------------------------------------- 8 2.1.1.4 Les informations à échanger entre partenaires----------------------------------- 9 2.1.1.5 Le réseau : La communauté des partenaires ------------------------------------ 10 2.1.1.6 Les typologies du réseau ---------------------------------------------------------- 11
2.2 Gestion de la Chaîne Logistique ----------------------------------------------------------- 12 2.2.1 La performance de la Chaîne Logistique ---------------------------------------------- 13
2.2.1.1 Le temps ----------------------------------------------------------------------------- 13 2.2.1.2 Le coût ------------------------------------------------------------------------------- 14 2.2.1.3 Le rendement ------------------------------------------------------------------------ 15 2.2.1.4 Evaluatuion mathématique de la performance ---------------------------------- 16 2.2.1.5 Calcul de la performance par simulation ---------------------------------------- 16
2.3 Modélisation de la chaîne logistique ------------------------------------------------------ 17 2.3.1 Modèles conceptuels --------------------------------------------------------------------- 18 2.3.2 Modèle SCOR ----------------------------------------------------------------------------- 19 2.3.3 Mise en oeuvre du modèle SCOR------------------------------------------------------- 20
2.4 Impact des technologies de l’information sur la chaîne logistique -------------------- 21 2.4.1 Les systèmes d’informations patrimoniaux -------------------------------------------- 22 2.4.2 Caractéristiques principales du système visé ------------------------------------------ 23
2.5 Conclusion ------------------------------------------------------------------------------------ 24
Chapitre 3 Collaboration et processus distribués----------------------------------- 26 3.1 Introduction ----------------------------------------------------------------------------------- 26 3.2 Le processus métier -------------------------------------------------------------------------- 27
3.2.1 Modélisation du processus métier ------------------------------------------------------ 27 3.2.2 Classification des processus métier ---------------------------------------------------- 29 3.2.3 Business Process Management ---------------------------------------------------------- 30
3.3 Le Workflow ---------------------------------------------------------------------------------- 31 3.3.1 WfMC et le modèle de référence pour le Workflow --------------------------------- 31 3.3.2 Modélisation du Workflow -------------------------------------------------------------- 33 3.3.3 ARIS ---------------------------------------------------------------------------------------- 34 3.3.4 Les avantages de la technologie de Workflow ---------------------------------------- 36 3.3.5 Organisation du processus métier en sous-flux --------------------------------------- 37 3.3.6 Processus métier et Workflow dans le e-business ------------------------------------ 38 3.3.7 Webflow ----------------------------------------------------------------------------------- 39
3.4 Organisation des processus distribués ----------------------------------------------------- 40 3.4.1 RM-ODP : modèle d’intégration -------------------------------------------------------- 41 3.4.2 Le processus public ----------------------------------------------------------------------- 43 3.4.3 Le processus privé ------------------------------------------------------------------------ 46 3.4.4 La liaison ---------------------------------------------------------------------------------- 47
Mayyad JABER vii
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
3.4.5 Gestion du processus public ------------------------------------------------------------- 48 3.5 Systèmes distribués et transactions -------------------------------------------------------- 51
3.5.1 Les transactions ACID ------------------------------------------------------------------- 52 3.5.2 Le rôle des transactions dans le processus métier commun ------------------------- 53 3.5.3 X / Open DTP ----------------------------------------------------------------------------- 54
3.6 Conclusion ------------------------------------------------------------------------------------ 56
Chapitre 4 Systèmes d’information distribués -------------------------------------- 57 4.1 Introduction ----------------------------------------------------------------------------------- 57 4.2 Intégration et échange : techniques existantes ------------------------------------------- 58
4.2.1 Premiers pas : l’EDI ---------------------------------------------------------------------- 59 4.2.2 Web EDI ----------------------------------------------------------------------------------- 59 4.2.3 Communication entre les briques logicielles : EAI et CORBA --------------------- 60
4.3 Interopérabilité technique ------------------------------------------------------------------- 63 4.3.1 Interopérabilité de données -------------------------------------------------------------- 63 4.3.2 Objets métiers et RM-ODP -------------------------------------------------------------- 64 4.3.3 Interopérabilité des systèmes d’information ------------------------------------------ 64
4.4 Architecture orientée service --------------------------------------------------------------- 65 4.4.1 Les avantages des architectures SOA -------------------------------------------------- 67 4.4.2 Pourquoi la SOA pour la chaîne logistique -------------------------------------------- 68 4.4.3 Composition des architectures SOA ---------------------------------------------------- 68 4.4.4 Implémentation de SOA ----------------------------------------------------------------- 69
4.5 Les Services Web ---------------------------------------------------------------------------- 70 4.5.1 Les standards utilisés par les services Web ------------------------------------------- 72
4.5.1.1 XML : eXtensible Markup Language -------------------------------------------- 73 4.5.1.2 SOAP : Simple Object Access Protocol ----------------------------------------- 73 4.5.1.3 WSDL : Web Services Description Language ---------------------------------- 74 4.5.1.4 UDDI : Universal Description, Discovery and Integration ------------------- 75
4.5.2 Gestion de transactions atomiques et validation en deux phases ------------------- 76 4.5.2.1 Les transactions atomiques -------------------------------------------------------- 76 4.5.2.2 Le protocole 2PC ------------------------------------------------------------------- 77
4.5.3 Modèles de transaction traditionnels --------------------------------------------------- 78 4.5.3.1 Busines Transaction Protocole ---------------------------------------------------- 78 4.5.3.2 Coordination et gestion de transaction pour les services Web---------------- 79
4.6 Conclusion ------------------------------------------------------------------------------------ 80
Chapitre 5 Principe de solution et feuille de route --------------------------------- 82 5.1 Introduction ----------------------------------------------------------------------------------- 82 5.2 Les différents modes d’interaction commerciales --------------------------------------- 83
5.2.1 Affaires à la volée : "On the fly Deals" ------------------------------------------------ 83 5.2.2 Collaboration stratégique ---------------------------------------------------------------- 84 5.2.3 Le mode hybride -------------------------------------------------------------------------- 84
5.3 Intégration des activités dans une chaîne logistique ------------------------------------- 85 5.3.1 Echange d’information ------------------------------------------------------------------- 86 5.3.2 Coordination du processus commun ---------------------------------------------------- 86
5.4 Feuille de route pour une architecture cadre --------------------------------------------- 90 5.4.1 Organisation d’un Workflow global : Composition du processus commun ------- 91
5.4.1.1 Interopérabilité des Workflows --------------------------------------------------- 92 5.4.1.2 Intégration des Workflows hétérogènes ----------------------------------------- 93 5.4.1.3 Le médiateur ------------------------------------------------------------------------ 94 5.4.1.4 Etude de cas : e-approvisionnement --------------------------------------------- 96
5.4.2 Interopérabilité et externalisation des processus métiers internes ------------------ 99 5.5 Conclusion ---------------------------------------------------------------------------------- 103
Chapitre 6 L’architecture cadre ----------------------------------------------------- 105
Mayyad JABER viii
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
6.1 Introduction --------------------------------------------------------------------------------- 105 6.2 L’architecture globale --------------------------------------------------------------------- 105
6.2.1 Organisation du moteur de Workflow global --------------------------------------- 107 6.2.2 Interconnexion de gestionnaires de Workflows distribués ------------------------ 109 6.2.3 Composition du Workflow global ---------------------------------------------------- 111
6.2.3.1 Publication des services associés aux processus internes ------------------- 112 6.2.3.2 Gestion et synchronisation de l’annuaire distribué -------------------------- 113 6.2.3.3 Échange de messages métiers et coordination -------------------------------- 114 6.2.3.4 Principe de fonctionnement ----------------------------------------------------- 115
6.3 Traitement pour l’interopérabilité de données ----------------------------------------- 117 6.3.1 Les objets métiers ----------------------------------------------------------------------- 118 6.3.2 Référentiel pour les objets métiers --------------------------------------------------- 118
6.4 Conclusion ---------------------------------------------------------------------------------- 121
Chapitre 7 Ressources distribuées et gestion de transactions -------------------- 123 7.1 Introduction --------------------------------------------------------------------------------- 123 7.2 La gestion de ressources distribuées ----------------------------------------------------- 124
7.2.1 Organisation de ressources distribuées----------------------------------------------- 126 7.2.2 Transition d’état d’une ressource ----------------------------------------------------- 127 7.2.3 Phases d’exécution --------------------------------------------------------------------- 128 7.2.4 Retour en arrière ------------------------------------------------------------------------ 130
7.3 Gestion de transaction --------------------------------------------------------------------- 132 7.3.1 Processus métier commun transactionnel -------------------------------------------- 133 7.3.2 Nesting (emboîtement) et notion de veto-Set --------------------------------------- 134 7.3.3 Hiérarchie des transactions Distribuées ---------------------------------------------- 135 7.3.4 Différentes phases d’exécution d’une transaction distribuée --------------------- 137 7.3.5 Notations pour les automates de gestionnaires de transactions ------------------- 139 7.3.6 Automate générique pour les algorithmes de gestionnaires de transactions ---- 141 7.3.7 Transition d’états du gestionnaire de transaction "racine" ------------------------ 143 7.3.8 Rôle du gestionnaire de transaction "inférieur" ------------------------------------- 152 7.3.9 Rôle du gestionnaire de transaction "supérieur/inférieur" ------------------------- 160
7.4 Conclusion ---------------------------------------------------------------------------------- 171
Chapitre 8 Implémentation du système gestionnaire de transaction ----------- 172 8.1 Introduction --------------------------------------------------------------------------------- 172 8.2 Cahier de charge --------------------------------------------------------------------------- 173 8.3 Plates-formes existantes ------------------------------------------------------------------- 176 8.4 JBoss ----------------------------------------------------------------------------------------- 178
8.4.1 Processus métier et orchestration : jBPM -------------------------------------------- 179 8.4.2 Gestion de services Web : JBoss WS ------------------------------------------------ 180 8.4.3 Gestion de transactions : JBoss Transactions --------------------------------------- 180 8.4.4 Discussion ------------------------------------------------------------------------------- 180
8.5 Etude de cas--------------------------------------------------------------------------------- 181 8.6 Prototype d’architecture ------------------------------------------------------------------- 185 8.7 Résultats ------------------------------------------------------------------------------------- 189 8.8 Conclusion ---------------------------------------------------------------------------------- 191
Chapitre 9 Conclusion générale et perspectives ----------------------------------- 193
Bibliographie --------------------------------------------------------------------------- 197
Annex A --------------------------------------------------------------------------------- 206
Mayyad JABER ix
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Table de figures Figure 2-1 Flux physique dans la chaîne logistique ------------------------------------------------------ 6
Figure 2-2 Les topologies de la Chaîne Logistique ------------------------------------------------------ 12
Figure 2-3 Modèle SCOR tiré de [SCC, 2008], p. 3 ----------------------------------------------------- 19
Figure 3-1 Modèle générique pour un processus métier ------------------------------------------------ 28
Figure 3-2 Modèle de référence pour le Workflow [Hollingsworth, 1995] -------------------------- 32
Figure 3-3 Architecture ARIS pour le processus métier [Scheer, 1998] ------------------------------ 35
Figure 3-4 Construction du processus commun à partir de sous-processus -------------------------- 37
Figure 3-5 Exemple de processus public ------------------------------------------------------------------ 45
Figure 3-6 La liaison entre deux processus, privé et public -------------------------------------------- 48
Figure 3-7 Modèle X/Open DTP [Stanford, 1997] ------------------------------------------------------ 54
Figure 4-1 Notion client/serveur avec le bus de CORBA, [Geib and Merle, 2000], (p. 7). -------- 61
Figure 5-1 Exemple de processus métier distribué. ----------------------------------------------------- 89
Figure 5-2 Feuille de route pour l’architecture cadre --------------------------------------------------- 91
Figure 5-3 (A) Workflow formel – (B) Workflow Ad hoc --------------------------------------------- 93
Figure 5-4 Rôle du Médiateur ------------------------------------------------------------------------------ 95
Figure 5-5 Rôle de médiateur dans un e-approvisionnement ------------------------------------------- 97
Figure 5-6 Processus commun à base de services ------------------------------------------------------- 99
Figure 5-7 Le rôle de services Web comme des interfaces ------------------------------------------- 101
Figure 5-8 Sélection de services intégrant un registre local destiné à améliorer le processus de
sélection ----------------------------------------------------------------------------------------------------- 103
Figure 6-1 Un cadre générique de système d’information coopératif ------------------------------- 106
Figure 6-2 Liens entre les composants du moteur de Workflow ------------------------------------- 108
Figure 6-3 Vue conceptuelle du connecteur. ----------------------------------------------------------- 111
Figure 6-4 Objets métiers et composition de services ------------------------------------------------- 119
Figure 6-5 Association des objets métiers basée sur les rôles---------------------------------------- 120
Figure 7-1 Exemple de processus sur une chaîne logistique ----------------------------------------- 125
Figure 7-2 Mécanisme d’Allocation de Ressources --------------------------------------------------- 127
Figure 7-3 Transition d’état d’une ressource ----------------------------------------------------------- 128
Figure 7-4 Transition d’état d’une ressource dans un processus commun -------------------------- 129
Figure 7-5 Retour en arrière ------------------------------------------------------------------------------ 131
Figure 7-6 Composition du processus commun transactionnel -------------------------------------- 133
Figure 7-7 Exemple d’une hiérarchie de transaction distribuée-------------------------------------- 136
Figure 7-8 Hiérarchie de gestionnaires de transactions distribuées --------------------------------- 137
Figure 7-9 Automate générique pour les gestionnaires de transactions ----------------------------- 143
Figure 7-10 Transitions d’état pour un gestionnaire de transaction racine ------------------------- 145
Figure 7-11 Gestionnaire de transaction racine -------------------------------------------------------- 151
Figure 7-12 Gestionnaire de transaction Inférieur ----------------------------------------------------- 160
Figure 7-13 Gestionnaire de transaction Supérieur/Inférieur ---------------------------------------- 170
Figure 8-1 Architecture du marché destinée à supporter le processus commun ------------------- 175
Figure 8-2 Architecture modifiée de la plate-forme --------------------------------------------------- 181
Figure 8-3 Services Web participant au processus commun d’e-approvisionnement ------------- 183
Figure 8-4 Différentes configurations pour le processus commun d’e-approvisionnement ------ 184
Figure 8-5 Rôle du composant factory dans le processus commun transactionnel ---------------- 186
Figure 8-6 Diagramme de séquence pour les composants du processus commun ----------------- 188
Mayyad JABER x
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 8-7 Intégration des gestionnaires de transaction dans les differentes configurations du
processus d’e-approvisionnement ------------------------------------------------------------------------ 190
Figure 8-8 Structure du fichier WSDL pour le factory ------------------------------------------------ 191
Mayyad JABER xi
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 1
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 1 Introduction générale
Afin de répondre aux exigences du marché et renforcer leur
compétitivité, les entreprises individuelles sont de plus en plus forcées à
l’ouverture sur leur environnement. En s’appuyant sur les technologies
de l’information et de la télécommunication (ICT), ces entreprises
cherchent à coupler efficacement leurs processus métiers (Business
Process BP) et leur Systèmes d’Information avec ceux de leurs
partenaires. L’échange d’informations entre les partenaires prend alors
une place primordiale pour améliorer la performance du réseau
d’entreprises. Toutefois, les fonctions de gestion de l’entreprise
individuelle sont orientées vers une seule organisation. En revanche, le
système de gestion pour la chaîne logistique doit étendre ces fonctions
pour englober les activités collaboratives de l’ensemble des entreprises
partenaires. Pour ce faire, un système d’information commun devient
indispensable. Ce système d’information doit offrir les moyens
nécessaires pour aider les responsables de la chaîne d ’entreprises à
mieux gérer leurs activités communes en s’appuyant sur ses facilités.
L’objectif ultime derrière un tel système est de participer à
l’amélioration de performance globale de chaîne logistique. Du point de
vue opérationnel et afin de réaliser ces objectifs, le système
d’information global doit faciliter l’accès aux informations permettant
ainsi l’échange de données inter-organisationnel. Pour une entreprise
individuelle, l’ouverture sur l’environnement représente le premier pas
vers la collaboration avec les autres membres de la chaîne logistique.
Le sujet de thèse s’inscrit dans le cadre du projet COPILOTE
(Collaboration et partage d’information dans les chaînes logistiques), il
s’inscrit plus particulièrement dans la tâche : Etude d’architectures
distribuées supportant le partage d’information. Il s’agit de concevoir
une architecture distribuée supportant les échanges d ’information entre
entreprises en se basant sur des travaux réalisés dans le cadre d ’une
Mayyad JABER 2
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
analyse des approches et outils collaboratifs existants pour la chaîne
logistique.
Pendant la durée de cette étude, nous avons orienté notre travail
sur la proposition d’un cadre d’assemblage pour un Système
d’Information partagé. Pour cela, nous avons intégré dans l’organisation
de l’architecture à la fois la gestion de processus métier interentreprises
(modélisation, règles de gestion, etc.), la modélisation des modes de
collaborations, des échanges et des informations échangées. Afin de
garantir l’évolutivité de la solution, l’architecture cadre a été conçue de
manière modulaire en développant une logique "d’assemblage" de
briques applicatives de haut niveau. Ce cadre, qui conduit à construire
un système d’information global, vise à regrouper les différents
systèmes d’informations patrimoniaux des partenaires. Ce système
global constitue l’infrastructure informatique de la chaîne logistique.
L’objectif de la construction d’un tel système est de répondre aux
exigences croissantes du marché ainsi que la réduction de coût des
produits finaux, le stock moyen, et le temps d’accès au marché. Un autre
objectif du système d’information visé est d’améliorer la collaboration
entre partenaires afin de répondre dynamiquement aux nouvelles
opportunités ou bien aux changements des conditions dans le marché.
Ce travail est divisé en deux parties, la première (du chapitre 2
jusqu’au chapitre 4) est consacrée à la description de l’état de l’art de la
chaîne logistique et les systèmes coopératifs dans ce contexte. Dans ce
cadre, nous verrons tout d’abord (Chapitre 2) les aspects génériques de
la chaîne logistique, ses éléments, les typologies possibles et la
méthodologie de modélisation pour les processus entre entreprises, ainsi
que les critères liés à la performance de la chaîne logistique et l’impact
des systèmes d’informations sur la performance. A la fin de ce chapitre,
nous aurons un cahier de charge pour le système d’information
interentreprises visé qui sert comme un guide pour la construction de
notre architecture cadre.
Vu la place importante du processus métier dans le contexte de
la chaîne logistique, le Chapitre 3 porte sur les aspects du processus
métier. En effet, le processus métier sert d’élément de base pour
l’élaboration du processus commun collaboratif interentreprises. Nous
présenterons aussi les aspects de Workflow comme un outil
d’automatisation pour le processus métier. Nous abordons aussi les
Mayyad JABER 3
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
adaptations nécessaires pour le domaine de e-business. En s’appuyant
sur les concepts du processus métier et de Workflow, nous introduisons
l’organisation du processus commun interentreprises avec les notions de
processus, public, privé et la liaison comme des éléments de base pour la
construction du processus commun de la chaîne logistique avec un
couplage lâche. La nature distribuée et le couplage lâche du processus
commun imposent une organisation spécifique pour garantir son bon
fonctionnement lors de la phase d’exécution. À cet effet, nous
introduisons à la fin de ce chapitre la notion de transaction comme une
solution pour réorganiser le processus commun de manière à renforcer
sa fiabilité et garantir sa cohérence.
Nous nous intéresserons ensuite (Chapitre 4) aux systèmes
d’information distribués qui servent de support pour le processus métier.
Nous commençons par les techniques existantes en nous attachant plus
particulièrement à leurs fonctionnalités dans le domaine du B2B. Nous
abordons ensuite la problématique de l’interopérabilité technique entre
les systèmes patrimoniaux. A cet effet, nous introduisons la SOA
(Architecture Orientée Service) qui offre une solution modulaire pour la
construction de système d’information global interentreprises. Nous
proposons l’utilisation de services Web pour l’implémentation de
l’architecture orientée service. Nous traitons les standards de services
ainsi que les transactions de service Web (Web Service Transaction) à la
fin du Chapitre 4.
Dans la deuxième partie (à partir du Chapitre 5), nous
focalisons notre travail pour proposer un cadre générique d’un système
d’information distribué interentreprises. Ce cadre exploite les principes
et les techniques mentionnés dans la première partie. Dans le Chapitre 5,
nous introduisons le principe de solution avec une feuille de route pour
l’architecture cadre. Pour cela, nous traitons les aspects liés à
l’intégration des activités de la chaîne logistique ainsi que l ’échange
d’information, la coordination et la composition du processus commun
sous forme de Workflow global. Nous proposons aussi une solution pour
résoudre le problème de l’interopérabilité entre les Workflows
hétérogènes.
A ce stade, nous présentons l’architecture cadre (Chapitre 6)
avec l’organisation du Workflow global distribué et un traitement
spécifique pour l’interopérabilité de données basé sur les objets métiers.
Mayyad JABER 4
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le Chapitre 7 est consacré pour la gestion de ressources et de
transactions distribuées. Nous proposons une organisation de ressources
distribuées afin de contrôler l’accès aux ressources par les différents
acteurs du processus commun. Ensuite, nous intégrons un système de
gestion de transactions distribuées pour garantir le bon fonctionnement
du processus commun. Ce système sera détaillé tout au long le reste du
Chapitre 7.
Dans le Chapitre 8, nous proposons d’implémenter un
prototype d’un processus commun interentreprises. Nous élaborons une
architecture distribuée pour la mise en œuvre d’un processus commun
qui est conforme notamment avec les aspects transactionnels. A cet
effet, nous utilisons une plate-forme du marché et nous l’adaptons afin
d’intégrer le système de gestion de transaction distribuées présentés
dans le Chapitre 7.
Nous terminons ce mémoire avec une conclusion générale et les
perspectives ouvertes par notre travail.
Mayyad JABER 5
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 2 Contexte
2.1 Introduction
L’image traditionnelle de l’entreprise peut être représentée comme une
unité de travail où les compétences sont regroupées dans une seule
organisation. Aujourd’hui, la tendance de facto est de regrouper
plusieurs entreprises au sein d’une organisation étendue ou d’une chaîne
logistique (en anglais Supply Chain SC) pour que chaque entreprise
membre puisse se concentrer sur les activités liées à son cœur de métier.
Il s’agit de se mettre d’accord pour permettre aux partenaires d’accéder
aux informations propres à l’entreprise afin d’améliorer les conditions
concernant les échanges commerciaux. La nature spécifique de
l’information échangée (les informations sont réservées aux partenaires
et non pas aux clients) impose d’organiser les relations (volontaires et
confidentielles) par le biais de contrats sous forme d’une organisation
virtuelle. Ce nouveau paradigme représente la notion d’entreprise
étendue ou virtuelle. Dans le cas où l’accent est mis sur les liens
commerciaux (achats, ventes) stables à moyen ou long terme entre les
partenaires, on peut parler d’organisation d’une chaîne logistique. La
chaîne logistique peut être définie comme un processus intégré, où
plusieurs entités représentant des métiers différents (fournisseurs,
fabricants, distributeurs et détaillants) coopèrent afin d’acquérir les
matières premières et par la suite, transformer ces matières en produits
finaux, les livrer aux détaillants (si besoin) puis aux clients finaux. La
Figure 2-1 représente le flux physique dans la chaîne logistique
[Beamon and Benita, 1998] [Barnett and Miller, 2000].
Mayyad JABER 6
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 2-1 Flux physique dans la chaîne logistique
En se basant sur cette définition, la chaîne logistique peut être
présentée comme un réseau d’entreprises où le flux de produits et/ou de
services est effectué dans un sens unique. Ce flux est initié par les
fournisseurs de matières premières et se termine par la livraison aux
clients finaux en passant par les fabricants de composants
intermédiaires, le fabricant de produits finis, les grossistes et les
détaillants. Les entreprises qui forment les nœuds de la chaîne logistique
sont connectées, au niveau physique, par les activités de transport et de
stockage, activités sur lesquelles s’appuie le flux de produits. Par
ailleurs, ces nœuds sont connectés au niveau informatique via des
processus communs (de collaboration). Ces processus communs forment
la source de la valeur créée par la chaîne logistique. L’objectif principal
de notre travail est de répondre à la question suivante : comment aider
les entreprises à mieux collaborer et ainsi améliorer la performance
globale de la chaîne logistique ? En effet, notre contribution est
consacrée à favoriser l’augmentation de la valeur créée par la chaîne
logistique. Cet objectif peut être atteint par la proposition de moyens
permettant de supporter un bon fonctionnement du processus métier
commun entre les partenaires de la chaîne logistique. Aussi, dans les
paragraphes suivants, nous étudierons plus spécifiquement les
composants de la chaîne logistique afin de déterminer les facteurs
participant à la création de la valeur ajoutée.
Mayyad JABER 7
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
2.1.1 Notions de base de la chaîne logistique
Avant d’aller plus loin sur la collaboration dans la chaîne logistique,
nous allons en présenter les éléments de base et plus particulièrement
ceux qui sont liés directement à la génération de la valeur ajoutée afin
d’avoir une vision plus claire sur la structure de la chaîne logistique au
niveau physique et donc nous aider à proposer des solutions pour
augmenter la valeur engendrée par la création de la chaîne logistique.
La chaîne logistique est structurée pour créer de la valeur
introduite par une opportunité du marché. Cette valeur est créée lors de
l’activation du processus représentant l’objectif de cette chaîne. Nous
dégageons trois éléments principaux qui contribuent à la création de
valeur : la valeur potentielle de l’opportunité, l’opération virtuelle et le
réseau de partenaires. Ces éléments seront détaillés dans les paragraphes
suivants.
2.1.1.1 La valeur : Le moteur qui conduit la Chaîne Logistique
La valeur potentielle est la force qui motive la construction de la chaîne
logistique. Les éléments suivants sont des exemples pouvant servir
comme des motifs pour la création de la chaîne logistique : [Katzy and
Schuh, 1998]
Proposer des solutions ou des produits spécifiques pour un client.
Offrir de nouveaux services industriels aux partenaires.
Faire face à l’évolution du marché en s’adaptant aux nouvelles
exigences induites.
Se focaliser sur la fabrication de produits particuliers, notamment en
apportant des garanties de qualité.
Se focaliser sur des compétences métiers associées au cœur de
métier de l’entreprise.
Traditionnellement, la valeur est générée par l’exploitation de
la main-d’œuvre et la consommation des ressources. Par contre, dans les
organisations virtuelles comme la chaîne logistique, la valeur est aussi
créée quand de nouvelles occasions commerciales apparaissent dans leur
environnement (champs d’activités). Une nouvelle structure industrielle
est alors construite pour exploiter ces opportunités.
Mayyad JABER 8
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
2.1.1.2 La source de valeur et la nature de la chaîne logistique
La chaîne logistique est une organisation basée sur la possibilité de créer
des coopérations entre entreprises. Ces coopérations, limitées dans le
temps, permettent de saisir collectivement des occasions commerciales
que les partenaires ne pourraient pas saisir individuellement. La valeur
est directement liée à la création du processus de la chaîne logistique et
non à l’amélioration d’un processus propre à un partenaire. Cela fait la
différence entre la gestion traditionnelle (entreprises individuelles) et les
approches utilisées pour la gestion de la chaîne logistique [Katzy and
Schuh, 1998]. En effet, la source de valeur dans la chaîne logistique
réside dans l’exploitation des occasions issues de son environnement.
Ces opportunités sont considérées comme un moteur économique qui
peut être alimenté par des sources variées : un nouveau marché,
(produit, service) ou l’intégration d’un nouveau partenaire industriel.
Une autre réalité à prendre en compte est la nature temporelle de la
chaîne logistique. La chaîne logistique est une coopération à caractère
limité dans le temps ayant pour objet la réalisation d’objectifs précis.
Afin de bénéficier de nouvelles occasions apparaissant sur le marché, les
entreprises doivent établir une relation de coopération et donc aller au-
delà de leur frontière. Cette relation est de nature dynamique, c’est-à-
dire qu’elle doit être adaptable en fonction de l’évolution du marché
(pour répondre à un objectif précis) et disposer d’un minimum de
coordination formalisée. Par conséquent, la nature de la chaîne
logistique conduit à un besoin permanent de restructuration des
processus de l’entreprise. Pour permettre l’adaptation continue de la
chaîne logistique, il faut disposer des moyens nécessaires pour réagir
efficacement en fonction des changements de l’environnement. En
particulier, l’agilité des échanges de données (et donc des moyens
associés mis à disposition des partenaires) est la clef pour bâtir des
processus coopératifs (opération virtuelle) entre les partenaires de la
chaîne logistique. Cette opération virtuelle forme un élément essentiel
lors de la création de la chaîne logistique.
2.1.1.3 L’opération virtuelle
Les opérations virtuelles permettent de faire face aux obstacles
techniques ou organisationnels au niveau opérationnel. Cela est atteint
en reconstruisant les processus métiers de manière à permettre le
Mayyad JABER 9
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
dépassement des frontières entre les entreprises. Les opérations
virtuelles implémentent les processus communs et assurent la liaison
entre les compétences et les ressources. Elles sont construites sur les
opportunités de coopération entre les partenaires de la chaîne logistique,
pour une durée précise, afin de créer une valeur à partir d’une
opportunité de business [Chandrashekar and Schary, 2002].
Pour cela, les entreprises cherchent à coupler leurs processus
privés avec ceux de partenaires afin de réaliser efficacement un objectif
métier commun. La construction du processus commun interentreprises
nécessite des facilités spécifiques permettant la mise en place et
l’exécution de l’opération virtuelle. A cet effet, une architecture qui
regroupe l’ensemble des facilités requises est indispensable afin de
permettre la mise en œuvre du système d’information support pour
l’opération virtuelle.
Grâce aux technologies de l’information et de la
communication, nous visons la construction d’un cadre générique pour
un système supportant l’opération virtuelle de la chaîne logistique.
Compte tenu de la nature temporelle de la chaîne logistique, le système
requis doit être capable de répondre aux exigences d’agilité à la fois
pour la conception et pour l’exécution de processus commun.
La création du processus commun est fondée sur la possibilité
d’échanger des informations entre les partenaires de la chaîne logistique.
Nous allons présenter différents types d’information à échanger suivant
les niveaux décisionnels dans la chaîne logistique.
2.1.1.4 Les informations à échanger entre partenaires
Avant de pourvoir exécuter un processus de coopération au sein de la
chaîne logistique, les entreprises participantes ont besoin d’échanger des
informations nécessaires pour la gestion des processus communs. Le
choix des informations nécessaires dépend à la fois des objectifs à
atteindre et du niveau de décision auquel on se trouve [Katzy and Schuh,
1998],[SCC, 2008]
Le niveau stratégique est associé à la phase de construction de la
chaîne logistique. Les informations à partager concernent :
o La construction de la chaîne logistique en se basant sur les
informations concernant les partenaires et la description des
Mayyad JABER 10
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
objectifs de la chaîne logistique et les engagements des
partenaires par rapport à ces objectifs.
o La gestion des relations entre les entreprises participantes.
o L’accord sur les conventions d’échange de l’information.
Le niveau tactique est dédié à la coordination des activités entre
entreprises. Les informations nécessaires concernent :
o La planification d’approvisionnement.
o La stratégie de fabrication.
o Les prévisions de la demande.
Le niveau opérationnel est centré sur les tâches liées aux activités
ayant lieu durant l’exécution du processus commun. La mise à jour
des instances de processus adaptables est aussi une tâche principale
de ce niveau.
Dans notre travail, et afin de limiter le champ d’études, nous
avons orienté notre action sur les deux derniers niveaux : niveau tactique
et niveau opérationnel. Notons toutefois que nous présenterons notre
vision liée au niveau stratégique (création de la chaîne logistique)
lorsque cela sera nécessaire.
2.1.1.5 Le réseau : La communauté des partenaires
Un des composants principaux de la chaîne logistique est le réseau
d’entreprises. L’un des avantages d’organiser le réseau d’entreprises est
la possibilité de réduire l’investissement nécessaire pour répondre à une
opportunité venant du marché en permettant à une entreprise de
s’appuyer sur les compétences des partenaires et sur leurs structures
industrielles patrimoniales [Lambert et al., 1998]. Nous allons souligner
quelques éléments permettant de caractériser les réseaux d’entreprises :
L’importance des régions géographiques : (matières premières,
main-d’oeuvre, situation politique…..)
Les frontières du réseau peuvent être dérivées de frontières
industrielles
Les frontières du réseau peuvent être dérivées d’une structure de
propriété
Il existe plusieurs possibilités d’organisation du réseau
d’entreprises. Afin d’étudier l’impact des technologies de l’information
Mayyad JABER 11
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
et de la communication (TIC) sur ces réseaux, nous allons présenter
différentes typologies de chaînes logistiques.
2.1.1.6 Les typologies du réseau
Afin de mieux répondre aux exigences d’intégration (niveau technique,
organisationnel…) des partenaires de la chaîne logistique, nous allons
classer les modèles de réseaux existants en différentes catégories. Pour
cela, nous nous basons sur la topologie des échanges entre partenaires
(structure de l’organisation, flux de matières) mais aussi sur les aspects
relationnels (puissance, relations de domination). Nous distinguons trois
catégories principales : (Figure 2-2)
Chaîne Logistique orientée processus : le but principal de cette
organisation est de mettre en œuvre un processus « de bout en bout »
depuis l’approvisionnement en matières premières jusqu’aux
produits finaux. L’échange de données dans ce type de chaîne
logistique est mené « séquentiellement » entre partenaires
« adjacents ». En conséquence, plusieurs adaptations sont
nécessaires entre les systèmes d’information patrimoniaux de chaque
partenaire.
La topologie en étoile (construite autour d’un donneur d’ordre) :
dans cette catégorie, une entreprise dominante contrôle l’ensemble
de la chaîne logistique afin de satisfaire la demande de sa clientèle.
Le problème de l’échange de données est donc réduit à l’adaptation
mutuelle entre les structures informatiques de l’entreprise dominante
et des entreprises dominées.
La topologie point à point (orientée projet) : la chaîne logistique
dans ce cas est organisée selon la fameuse structure spaghetti et
conduit donc à des canaux de connexion multiples. Cette
organisation est établie pour réaliser un projet à court terme.
L’adaptation des systèmes d’information doit donc être effectuée à la
volée en garantissant l’interopérabilité entre les différents systèmes
d’information impliqués.
Mayyad JABER 12
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 2-2 Les topologies de la Chaîne Logistique
Dans le monde réel, il est fréquent qu’une entreprise participe à
plusieurs chaînes logistiques ou organisations collaboratives à la fois.
Afin d’éviter l’adaptation du système d’information patrimonial pour
chaque cas, il convient de mettre en place une structure ouverte pour le
système d’information global, structure représentant l’objectif de notre
travail de recherche. Afin d’en définir le cahier des charges, nous
proposons de nous intéresser d’abord aux modes de gestion et en
étudiant plus précisément les mesures de performance globales ainsi que
l’influence du partage des données sur ce niveau de performance.
2.2 Gestion de la Chaîne Logistique
La littérature propose plusieurs définitions pour le processus de gestion
de la chaîne logistique (ou Supply Chain Management (SCM) en
anglais). Le Supply Chain Council définit le SCM comme : « contrôler
l’approvisionnement et la gestion des commandes, approvisionner les
matières premières et les composants, fabriquer et assembler les
produits, piloter l’entreposage et le stockage, noter et diriger les
commandes, effectuer la distribution en travers le réseau des
entreprises, et livrer les produits finis aux clients » [Lummus and
Vokurka, 1999] (p. 11).
Une autre définition propose de considérer le SCM comme le
design et le management d’un processus continu inter-organisationnel
qui porte de la valeur ajoutée, afin de satisfaire les demandes réelles des
clients finaux [Lambert et al., 1998].
Mayyad JABER 13
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
L’enjeu du SCM est d’optimiser le fonctionnement de la chaîne
logistique, optimiser étant pris au sens d’augmenter les profits nets pour
chaque partenaire. Pour ce faire, un pilote global doit être mis en place
pour coordonner les différentes activités commerciales des entreprises
membres. Ce pilote dirige le processus commun (qui est l’objectif pour
lequel la chaîne logistique a été construite) source de la valeur crée. Le
processus commun est composé à partir de plusieurs processus
"individuels" (ou privés) appartenant à au moins deux partenaires de la
chaîne globale. Ce processus commun permet donc l’échange de
données efficace entre les partenaires et offre ainsi un support
fonctionnel pour le partage de l’information au sein de la chaîne
logistique.
2.2.1 La performance de la Chaîne Logistique
Avant de présenter les différents modèles de la chaîne logistique qui
peuvent aider à étudier la performance globale, nous allons étudier les
facteurs qui affectent cette performance. Il s’agit des mesures qui
donnent une vision précise (chiffrée) sur le déroulement du processus
commun. Ces mesures (temps, coût et rendement) peuvent montrer
l’influence de la collaboration entre les partenaires et donc les effets de
la mise en œuvre d’un système d’information global pour la gestion de
chaîne logistique. C’est pour appréhender ce dernier point que nous
introduisons les différents critères de performance. Les paragraphes
suivants portent sur les critères et les modèles contribuant à mesurer la
performance globale de la chaîne logistique.
2.2.1.1 Le temps
Le temps est une mesure facile à acquérir. Il s’agit d’effectuer deux
observations et de les dater avant de faire la soustraction. La période la
plus intéressante à mesurer pour les chaînes logistiques est celle d’un
processus métier : il s’agit de mesurer la durée nécessaire pour
l’exécution du processus métier à partir de son initiation et jusqu’à sa
terminaison. Les processus en jeu peuvent être mesurés à n’importe
quelle échelle allant de la seconde à plusieurs mois [Taylor, 2004].
Les délais qui ne sont pas directement liés à un seul processus
sont habituellement repérés par intervalles. Un intervalle peut être le
Mayyad JABER 14
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
temps qui s’écoule entre les ordres d’un client particulier. Cet intervalle
de temps pourrait aller de quelques heures à quelques semaines. Il existe
d’autres types de mesure liés au temps comme le débit. Le débit est
défini comme étant les unités de travail divisé par une unité de temp s.
Un exemple de débit est le nombre de commandes traitées par jour.
Quelle que soit la mesure de temps prise en considération
(durée de processus métier, intervalle, débit), la mise en œuvre d’un
système d’information global peut visiblement améliorer les
performances. En effet, un système d’information global permet
d’épargner le temps nécessaire pour l’échange de données liées à
l’approvisionnement, la livraison et le paiement. Cela peut participer à
la réduction les intervalles entre les exécutions successives des
processus et en conséquence augmenter le débit du processus commun.
2.2.1.2 Le coût
La deuxième grande catégorie de mesure est le coût. Il s’agit du
paramètre le plus important pour évaluer la performance de la chaîne
logistique. Différents types de mesures de coûts sont envisageables. Par
rapport à la simplicité de la mesure du temps, la mesure des coûts est
nettement plus difficile. En principe, deux types de coûts sont à prendre
en compte [Taylor, 2004]:
Les frais directs : ce sont les coûts attribués directement à la
production des produits finis. Cette catégorie comprend le coût des
matières premières ainsi que le coût des processus nécessaires pour
acquérir ces matériaux, les transformer en produits finis et les livrer
aux clients.
Les frais indirects : il s’agit des coûts nécessaires pour l’exploitation
de l’entreprise. Ces coûts ne peuvent pas être attribués directement à
la création d’un produit particulier. Il s’agit notamment des coûts
d’achat et d’entretien de l’équipement utilisé dans la production, des
coûts de construction et d’exploitation des installations de
l’entreprise. En général, ces coûts sont calculés en les répartissant
sur les produits selon une règle propre à chaque entreprise.
Tous les coûts sont dus à l’utilisation des ressources par les
processus. Le système d’information global participe à réduire à la fois
Mayyad JABER 15
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
les frais directs et indirects. En effet, l’application des technologies de
l’information et de la communication pour supporter le processus
commun de la chaîne logistique réduit la consommation de ressources
(humaines, machines, matériels) nécessaires pour l’exécution de ces
processus. Ainsi la chaîne logistique devient plus compétitive. Cela
conduit à augmenter le chiffre d’affaire pour chaque entreprise de la
chaîne logistique, et en conséquent, à améliorer le ratio frais
indirecte/chiffre d’affaire.
2.2.1.3 Le rendement
Le coût est une mesure essentielle pour la chaîne logistique. Toutefois,
cette mesure ne rend pas compte d’un aspect important : l’efficacité
avec laquelle une chaîne utilise ses ressources. Si les facilités, les
installations, les équipements, les véhicules et les autres ressources ne
sont pas utilisés à (ou près de) leur pleine capacité, les coûts indirects
doivent être répartis sur moins de produits. Cela participe à augmenter le
coût de ces produits. La mesure du rendement permet d’évaluer
l’efficacité avec laquelle une chaîne utilise ses éléments patrimoniaux
[Taylor, 2004].
Parmi les nombreuses mesures du rendement dans la chaîne
logistique, le stock général reçoit le plus d’attention à cause de son
poids financier. Plusieurs mesures sont utilisées pour surveiller les
niveaux de stocks, y compris le stock réel et le stock moyen. La mesure
la plus couramment utilisée est le ratio de rotation des stocks. Le ratio
de rotation pour un produit est le chiffre annuel des ventes de ce produit
divisé par le stock moyen.
La disponibilité de l’information sur le stock fournie par le
support informatique (grâce à un système d’information global) permet
aux partenaires de réduire les quantités commandées. Ainsi, le stock
moyen est réduit ce qui réduit le coût de stockage et augmente le
rendement pour la chaîne logistique.
Compte tenu de la place importante des mesures de
performance, nous allons présenter deux méthodes permettant
d’appréhender ces mesures : les méthodes mathématiques directes et les
méthodes basées sur la simulation.
Mayyad JABER 16
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
2.2.1.4 Evaluatuion mathématique de la performance
Un modèle mathématique est une représentation particulière du système
dans lequel les relations sont définies par des équations. Il existe des
solutions numériques pour manipuler de tels modèles, mais le fait de
résoudre les modèles même les plus simples devient rapidement pesant.
En conséquent, cette tâche est résolue habituellement par des outils
informatiques. L’outil support le plus courant pour cette modélisation
mathématique est la feuille de calcul (spread sheet) ou le tableur tel que
Microsoft Excel. Son utilisation est étendue vers la construction de
modèles de business. Par exemple, les feuilles de calcul sont souvent
utilisées pour construire les prévisions de la demande. Bien sûr, les
feuilles de calcul ne sont pas les seuls outils pour la mise en œuvre de
modèles mathématiques. De nombreuses applications spécialisées dans
la chaîne logistique utilisent leurs modèles mathématiques spécifiques
pour accomplir leurs calculs [Barnett and Miller, 2000], [Taylor, 2004].
L’exploitation de modèles mathématiques offre des résultats
quantitatifs décrivant, avec un chiffrage précis, le comportement de la
partie du système étudiée. C’est un avantage pour le traitement de
systèmes complexes, comme la chaîne logistique, où nous avons besoin
de calculer les effets de la collaboration sur la performance globale.
La construction d’un modèle mathématique pour la chaîne
logistique constitue un objectif en soit et ne fait pas partie en tant que tel
de nos objectifs. Nous avons introduit l’existence des outils dédiés pour
la représentation mathématique de la chaîne logistique car ils
permettront de chiffrer l’amélioration de la performance globale obtenue
après la mise en œuvre d’un système d’information globale.
2.2.1.5 Calcul de la performance par simulation
Pour les systèmes ayant des relations connues entre les objets et pouvant
être décrits par des équations, les modèles mathématiques sont
généralement le meilleur moyen de modélisation. Toutefois, il n’est pas
toujours possible de convertir des relations entre objets en équations
simples permettant la résolution directe. Il faut aussi appréhender le
fonctionnement dynamique du système. Dans ce cas, les modèles de
simulation sont généralement une meilleure approche.
La construction d’une simulation consiste à programmer un
certain nombre d’objets logiciels. Ces objets jouent les rôles des objets
Mayyad JABER 17
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
du monde réel. Le système résultant est exploité pour voir comment ces
objets interagissent sous les conditions tirées du monde réel. Les objets
représentent des clients, des fournisseurs, des commandes, des
expéditions, des matériaux, des produits, ainsi que tous les autres
éléments de la chaîne logistique. Dans le programme, ces objets
communiquent les uns avec les autres tout comme ils le font dans le
monde réel. Avec des paramètres et des entrés/sorties représentant le
monde réel, le simulateur génère des résultats fiables indiquant la
vitesse à la laquelle la demande est satisfaite, le montant des stocks
détenus dans chaque entreprise, le coût total du processus commun et les
autres mesures de performance de la chaîne logistique. Les modèles de
simulation représentent les processus communs comme un ensemble
d’objets simulant le monde réel [Taylor, 2004].
L’analyse de la performance d’une chaîne logistique et le
comportement du processus commun peuvent aussi être envisagés en
étudiant la logique d’assemblage des processus privé. Pour cela, on peut
envisager de mettre en place un modèle générique basé sur l’assemblage
de processus privés. Dans les paragraphes suivants, nous allons aborder
la notion de modélisation de chaîne logistique par assemblage de
processus privés pour aboutir au processus global en nous intéressant
également à la logique d’assemblage.
2.3 Modélisation de la chaîne logistique
La chaîne logistique peut être vue selon la définition proposée dans la
section 2.1 comme un processus global, incluant essentiellement des
processus d’approvisionnement, de fabrication et de livraison des
produits ou des services. D’autres processus comme le transport, le
stockage, etc. forment un support indispensable pour compléter le
processus global interentreprises. Du coup, l’enjeu essentiel de la chaîne
logistique est de regrouper ces processus de façon à ce que la
performance globale soit optimale. Pour ce faire, nous allons présenter
les aspects concernant la modélisation formelle de la chaîne logistique.
L’objectif est de donner une vision détaillée sur son organisation et plus
particulièrement sur le processus commun, afin de déterminer les
caractéristiques du système d’information global nécessaire pour une
bonne gestion de la chaîne logistique.
Mayyad JABER 18
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
2.3.1 Modèles conceptuels
Un modèle conceptuel est une description de base pour un système. Ce
modèle doit être compréhensible par les gens du secteur métier et les
informaticiens. Un modèle conceptuel est représenté par le biais de
diagrammes utilisant une notation formelle afin de réduire l’ambiguïté.
Les diagrammes à utiliser peuvent varier selon l’objectif poursuivi par la
création du modèle.
Dans le contexte de la chaîne logistique, le système comporte
plusieurs types d’objets : entreprises, processus, ressources, etc. Ces
objets sont interconnectés afin de réaliser un objectif commun. Les
entreprises possèdent des ressources et exécutent des processus, les
processus consomment des ressources et en produisent d’autres. Les
ressources constituent la source des coûts et des valeurs dans le système.
En dépit de l’apparente simplicité des principes permettant de lier les
objets, un diagramme conceptuel qui comporte ces différents objets
(ressources, processus, etc.) avec leurs interconnexions devient assez
complexe.
Dans les paragraphes précédents, nous avons présenté
différentes approches pour modéliser la chaîne logistique. Ces modèles
offrent une vision plus claire sur les composants de la chaîne logistique
et leurs interconnexions. En se basant sur ces modèles, et plus
particulièrement les modèles mathématiques (soit par calcul direct soit
basé sur la simulation), nous pouvons chiffrer les éléments de la
performance de facto de la chaîne logistique (temps, coût rendement).
Ainsi, nous pourrons déterminer la performance atteinte à l’issue de la
mise en œuvre d’un système d’information global dédié à la gestion de
la chaîne logistique.
Par ailleurs, les modèles conceptuels peuvent aider les
personnes venant de différents domaines de business (direction,
production industrielle, études et développement…), à avoir une
compréhension commune du système. Le développement de modèles
spécifiques à la chaîne logistique, comme le modèle SCOR que nous
introduirons dans la section suivante, peut aider les responsables d ’une
chaîne logistique à réorganiser le système afin d’optimiser sa
Mayyad JABER 19
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
performance en proposant des processus standards, des objets métiers
bien définis et des composants de base du système d’information.
2.3.2 Modèle SCOR
L’optimisation de la chaîne logistique sollicite une parfaite
compréhension de ses activités. La méthode SCOR (Supply-Chain
Operations Reference) emploie un système de mesures intersectorielles
et standardisées pour l’analyse et l’amélioration des performances
opérationnelles d’une organisation [SCC, 2008].
Le modèle SCOR repose sur l’identification de cinq grands
processus de gestion désignés sous les termes Plan, Source, Make,
Deliver et Return (Figure 2-3), et prenant en compte les organisations
industrielles et logistiques (production sur stock ("Make To Stock"),
production à la commande ("Make To Order"), etc.). Ces processus sont
classés selon ces organisations de la production et décomposés en
éléments auxquels sont associés des "best practices".
La démarche de modélisation commence par un processus de
"Business Process Reengineering" permettant de modéliser une situation
à partir de "briques" de base proposées par le modèle. Cela se poursuit
par une étape de "benchmarking" à partir de tableaux d’évaluation
proposés dans une approche de partenariat avec les industriels adhérents
au Supply Chain Council, et se termine par l’analyse des "best practices"
proposées afin de définir le modèle de référence cible de l’entreprise
[Barnett and Miller, 2000].
Figure 2-3 Modèle SCOR tiré de [SCC, 2008], p. 3
Mayyad JABER 20
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
2.3.3 Mise en oeuvre du modèle SCOR
Le modèle SCOR peut être considéré comme un modèle de référence
pour la standardisation des activités au sein de la chaîne logistique en
intégrant des termes industriels. Ce modèle permet aux entreprises
d’améliorer leurs performances en les aidant à échanger les informations
entre partenaires liées aux activités de la chaîne logistique (le "quoi" et
le "comment"). De plus, il permet d’identifier les écarts en termes de
performance et de proposer une correction. La méthodologie pour
l’application de SCOR conduit une analyse des opérations de la chaîne
logistique en quatre niveaux [SCC, 2008]:
L’analyse de compétitivité : cette étape est dédiée à établir le
périmètre de la chaîne logistique, déterminer les mesures de
performance, identifier l’état actuel de la chaîne logistique en
complétant les SCORcards, déterminer les exigences compétitives en
terme de performance et compléter le SCORcard de l’analyse des
écarts.
La configuration de chaîne logistique : cette étape consiste à créer la
carte AS IS géographique, à identifier les distorsions et leurs
impacts sur le ROI (Return On Investment), à créer la carte TO BE
et enfin à déterminer l’organisation des processus pour les deux
configurations : AS IS et TO BE.
L’alignement de performance : il s’agit de définir la stratégie de
conduite du changement pour atteindre la performance visée. Cela
est réalisé par le développement de la carte AS IS pour les
informations et la mise en œuvre, identifier et mesurer les
distorsions, et développer les spécifications de design visé et la carte
TO BE d’information et d’ouvrage.
La mise en œuvre : afin de planifier la mise en application, une liste
priorisée des changements est indispensable. Afin de réaliser ces
changements, des calculs de bénéfices et de ressources requises
doivent être effectués.
La mise en œuvre complète de la procédure ci-dessus entraîne
un plan de business avec des projets priorisés pour améliorer la
Mayyad JABER 21
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
performance de la chaîne logistique. Le résultat est un processus
commun optimisé qui garantit la performance optimale de la chaîne
logistique. Ceci est fait grâce au re-design de processus existants, au
partage de connaissances sur les pratiques organisationnelles, et à
l’introduction de nouveaux processus, et plus particulièrement ceux qui
profitent de la technologie de l’information [Verwijmeren, 2004],
[Borges et al., 2005]. Notons toutefois que SCOR ne propose pas une
méthodologie pour la mise en œuvre du système au niveau technique
[SCC, 2008], c’est pourquoi nous complétons notre étude par un volet
plus technique sur les systèmes d’information et leur implication dans le
domaine de la chaîne logistique.
2.4 Impact des technologies de l’information sur la chaîne logistique
Plusieurs études ont montré l’effet positif du partage de l’information
dans la chaîne logistique [Lambert et al., 1998], [McLaren et al., 2004].
En effet, la disponibilité de l’information permet aux entreprises de
baisser leurs stocks de sécurité et le délai de livraison . En plus, la
diffusion des informations concernant la disponibilité des produits
permet aux clients de l’entreprise de mieux gérer leurs achats. A la
lumière des informations diffusées, les membres de la chaîne logistique
peuvent ajuster efficacement la fréquence de leurs commandes.
La disponibilité de l’information favorise donc de manière
incontestable l’anticipation et donc la réduction du temps d’accès au
marché. Un autre avantage est la réduction du stock moyen chez les
fabricants. Cela est réalisé en offrant un accès de temps réel aux
informations concernant le niveau de stock des fournisseurs et des
clients. Ces informations constituent les entrées pour la planification des
processus internes de chaque partenaire en harmonisation avec le
processus commun de la chaîne logistique.
En outre, le partage de données dans la chaîne logistique joue
un rôle crucial pour réduire le coût total d’un service ou d’un produit
fini et en conséquence, pour améliorer la compétitivité et les profits des
partenaires donc la performance globale.
A la lumière de la place importante prise par l’échange de
l’information au sein de la chaîne logistique, un système d’information
global pris comme un support du processus commun parait
Mayyad JABER 22
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
indispensable. Les investissements importants des entreprises
individuelles sur leurs systèmes d’information locaux empêchent de
recommencer la conception du système d’information « à zéro ». Cette
contrainte implique la réutilisation de ces systèmes d’information afin
de construire le système d’information global. Les composants
principaux du système global que nous envisageons sont donc les
systèmes patrimoniaux.
2.4.1 Les systèmes d’informations patrimoniaux
Les systèmes d’information impliqués dans la chaîne logistique sont
construits à partir de différentes "briques" comme les systèmes d’ERP,
de WMS (Warehouse Management Systems), de TMS (Transportation
Management Systems), etc. (Tableau 2-1). Ces briques applicatives sont
autant de logiciels et de progiciels [Vinoski, 1997], [Lazcano et al.,
2000]. Elles fournissent des fonctions dédiées au domaine d’application
et les bases de données qui leur sont associées et contiennent les
informations propres à l’entreprise. Ces logiciels fournissent à la fois les
moyens de coordination dans chaque entreprise et les interfaces
utilisateurs pour les utilisateurs internes.
Tableau 2-1 Quelques composants des systèmes d’information patrimoniaux
Les systèmes d’ERP, WMS et TMS se concentrent sur les
processus de chaque entreprise participante, et non pas sur le processus
commun. En conséquence, des systèmes supplémentaires sont requis
pour supporter la collaboration interentreprises (c’est-à-dire le processus
commun de la chaîne logistique).
Les
composants
ERP
Enterprise Resource
Planning
WMS
Warehouse
Management Systems
TMS
Transportation
Management Systems
Fonctions Achats, gestion de
matières, Ventes
Gestion de stock
traitement des
demandes
Réservation et
planification de
transport
Utilisateurs Entreprises fabricantes
et commerciales
Services logistiques,
grossistes
Transporteurs,
expéditeurs
Mayyad JABER 23
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
En s’appuyant sur les facilités offertes par les systèmes
patrimoniaux, notre objectif est de construire une architecture cadre
pour un système d’information global destiné à la gestion de la chaîne
logistique. Cette architecture doit remplir les exigences de flexibilité de
la chaîne logistique [Verwijmeren, 2004]. Dans le paragraphe suivant,
nous détaillons les exigences propres à la chaîne logistique pour la
construction de l’architecture cadre du système d’information global.
2.4.2 Caractéristiques principales du système visé
Comme nous l’avons expliqué dans les paragraphes précédents, les
entreprises font largement appel aux technologies de l’information et de
la communication pour effectuer leurs échanges commerciaux et
financiers. Les informations échangées dans ce contexte sont par
exemple les informations constiuant les demandes d’achats, les factures,
les notices de chargement, etc. L’implémentation de ce type de
collaboration requiert [Aalst, 2000], [Bakos, 1998] :
L’automatisation de l’extraction de données (ex. ordre d’achat) à
partir des applications internes (donc des systèmes patrimoniaux
concernés) chez un partenaire (que nous désignerons comme
Initiateur de l’échange).
La diffusion de ces informations vers un ou plusieurs partenaires
grâce aux facilités offertes par le système d’information global.
L’insertion automatisée de ces informations dans le système interne
d’un ou plusieurs partenaires (que nous appelons Répondeurs).
L’augmentation des standards liés au développement des
activités de marché virtuel est due principalement à l’utilisation de
langages pivots basés sur XML comme syntaxe de base pour les
informations échangées. Avec leur structure simple, ces langages
permettent de définir facilement des types variés de documents utilisés
par les différents logiciels. Notre objectif est d’utiliser les standards
orientés B2B pour faire face aux problèmes introduits par la croissance
en nombre des applications utilisées dans les entreprises voulant
anticiper leur intégration dans une chaîne logistique, et ce en vue de
résoudre des problèmes d’interopérabilité [Girard and Crusson, 2001].
La complexité des processus métier nous oblige à utiliser un
moyen pour simplifier les activités liées aux transactions entre les
Mayyad JABER 24
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
composants de l’organisation globale de la chaîne logistique. Une
solution envisageable est le Workflow. Avec des extensions pour les
processus de B2B, le Workflow offre un moyen important pour faciliter
la modélisation des processus d’interaction entre les entreprises
participantes. L’architecture de notre système doit satisfaire les
exigences suivantes :
L’indépendance des entreprises au niveau des informations privées
(Savoir faire, règles de business, etc.).
La facilité de maintenance du système complet (inclusion d’un
nouveau partenaire, exclusion d’un partenaire, changement de règles
de business).
La sécurité et la fiabilité de l’information échangée via le système
inter-organisationnel.
Le traitement des exceptions et des problèmes concernant l’aspect
temporel.
Dans ce travail, nous allons poser les principes concernant les
systèmes d’informations orientés chaîne logistique et nous allons surtout
traiter des mécanismes d’échange de données entre entreprises, au
travers de systèmes de Workflow distribués, afin d’offrir un
environnement flexible de coopération entre organisations.
2.5 Conclusion
Dans ce chapitre, nous avons introduit les notions de base de la chaîne
logistique ainsi que la performance et ses critères (le temps, le coût et le
rendement). Ensuite, nous avons abordé la modélisation de la chaîne
logistique et notamment le modèle SCOR. Nous avons aussi montré
l’impact important de technologie de l’information sur la gestion de la
chaîne logistique. Comme nous l’avons déjà mentionné, notre objectif
est de proposer une architecture cadre qui peut servir comme une base
pour un système d’information global dédié pour la gestion de la chaîne
logistique. Il s’agite plus précisément de proposer un cadre générique
permettant la mise en œuvre et l’exécution du processus commun
interentreprises. En effet, le processus commun peut être vu comme un
assemblage des processus métiers propres aux partenaires. C ’est pour
cela que nous consacrons le chapitre suivant pour introduire le processus
Mayyad JABER 25
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
métier et les techniques permettant la coordination de processus métier
distribué pour construire le processus commun.
Mayyad JABER 26
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 3 Collaboration et processus
distribués
3.1 Introduction
Dans le Chapitre 2, nous avons montré la place importante du processus
métier dans l’intégration de la chaîne logistique. En effet, le processus
métier représente un composant de base pour la construction du
processus commun dans la chaîne logistique. Pour améliorer la
compétitivité et offrir un service "clé en main" à la clientèle, les
entreprises doivent dépasser leurs propres limites et mettre en œuvre des
alliances efficaces ou des réseaux de collaboration. Les organisations
virtuelles résultantes sont fortement conditionnées par une relation de
confiance entre des partenaires complémentaires ou concurrents. Comme
cette tendance est renforcée par la diffusion des Technologies de
l’Information et de la Communication (ICT), de nouveaux enjeux sont
issus de ce cyber-partenariat comme par exemple la diminution de la
durée de vie de l’organisation virtuelle et l’implication potentielle dans
plusieurs réseaux de collaboration. Ces changements organisationnels
induisent des exigences d’interopérabilité pour le partage des processus
métiers et l’échange d’informations. Ces contraintes conduisent à
privilégier des infrastructures légères reconfigurables pour les systèmes
d’information et de communication.
Plusieurs études ont été menées en se focalisant soit sur le
Workflow inter-organisationnel et les processus métiers partagés [Shen
and Liu, 2001], [Aalst, 2000] ou sur l’application de l’architecture de
systèmes d’information distribués basé sur des composants comme les
services Web (WSs) [Albani et al., 2003], [Rabaey et al., 2003].
D’autres approches fondées sur les systèmes patrimoniaux propres aux
entités de business comme celle mise en œuvre dans le projet WISE,
Mayyad JABER 27
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
[Lazcano et al., 2000] peuvent être utilisées pour définir des modèles
appropriés. Dans le cas où la collaboration est réalisée dans un contexte
à très court terme, des architectures basées sur le B2B ou le E-
Commerce sont fréquemment utilisées [Papazoglou, 2003].
Dans ce travail, nous visons à proposer une solution intégrale
pour un système d’information global support de la chaîne logistique. En
se basant sur les processus métiers des partenaires, nous allons présenter
notre vision pour l’organisation du processus commun interentreprises.
3.2 Le processus métier
Le processus métier (ou Business Process) est un composant élémentaire
du processus global dans la chaîne logistique. Le processus métier est
défini comme un groupe d’activités qui permettent d’atteindre
collectivement un objectif de business dans un contexte inter-
organisationnel [Davenport and Short, 1990].
Un exemple typique de processus métier est le traitement d’un
ordre d’achat. Les activités constituant ce processus commencent par la
prise en compte de la commande et se terminent par la livraison au
client. Entre ces deux extrémités, plusieurs activités intermédiaires se
déroulent selon un chemin connu à l’avance afin de garantir le
fonctionnement correct et cohérent de ce processus. Un exemple de ces
activités intermédiaires est la vérification de niveau de stock pour les
articles demandés et dans le cas d’une réponse négative on devra
procéder au lancement du processus de fabrication [Aalst, 2000]. Dans
le cas où le processus de fabrication nécessite un processus
d’approvisionnement, une connexion vers un processus externe devient
indispensable ce qui introduit le processus commun de la chaîne
logistique. Afin de modéliser ce processus résultant, les notions
concernant la modélisation du processus métier sont présentées dans le
paragraphe suivant.
3.2.1 Modélisation du processus métier
Le processus métier peut être modélisé en utilisant des diagrammes
UML. En effet, UML est un langage de modélisation qui permet à la fois
de représenter graphiquement la structure dynamique des processus
Mayyad JABER 28
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
métier et de développer un modèle rigoureux, maintenable et traçable,
qui sert de référence durant le développement des supports
informatiques. Le modèle de processus métier doit présenter l’ensemble
des éléments ainsi que l’objectif ou la raison pour laquelle le processus a
été créé, l’événement provoquant son initialisation, les entrées, les
sorties, les ressources consommées, les activités réalisées et la séquence
d’exécution. Pour des raisons de généralisation, le processus métier peut
être appréhendé comme un regroupement récursif de sous-processus
jusqu’à ce qu’on arrive au niveau des tâches qui sont des activités non
décomposables. Un modèle générique pour la modélisation de processus
métier est développé dans le Chapitre 4. Ce modèle se concentre sur la
composition du processus commun en représentant les éléments de la
description du processus métier (voir ci-dessus) et qui permet en plus de
construire des processus métier à partir de méta-processus métier. Un
méta-modèle initial de processus métier est illustré dans la Figure 3-1.
Figure 3-1 Modèle générique pour un processus métier
Dans le domaine de la chaîne logistique, il existe plusieurs
types de processus métier. La modélisation de chaque type peut varier
selon les aspects qu’on veut mettre en évidence. En outre le classement
selon les types de processus nous permet de mettre l’accent sur des
Mayyad JABER 29
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
processus particuliers selon les différentes étapes du cycle de vie de la
chaîne logistique, et même de prendre en compte les différents aspects à
modéliser dans le modèle à construire. Le paragraphe suivant présente
une synthèse sur le classement des processus métier.
3.2.2 Classification des processus métier
Un processus métier peut être classifié [BPMI, 2007] selon :
La fréquence d’exécution
o Processus ad hoc : exécuté une fois, par ex. la construction
d’une chaîne logistique.
o Processus de production : haute fréquence, par ex. la
construction d’une série de maisons de même type.
o Processus de production de masse : très haute fréquence, par
ex. la production de voitures.
Le niveau administratif hiérarchique
o Processus primaire ou processus de production : ex. la
production de blocs dans une société de construction.
o Processus secondaire ou processus de soutien : ex. la
manipulation des outils de production
o Processus tertiaire ou processus de gestion : ex. management
de projet.
Le classement des processus métier nous permet d’analyser les
différentes exigences concernant la modélisation des processus selon
leur type. Par exemple, quand il s’agit d’un processus de production,
l’accent est mis sur la logique de construction afin de minimiser le
temps d’exécution. La logique de construction ou d’assemblage est aussi
importante pour la composition du processus métier commun. En
revanche dans ce dernier cas, l’objectif sera de garantir son bon
fonctionnement. A cet effet là, un outil efficace de management pour le
processus métier est nécessaire afin de faciliter l’intervention des
acteurs et utilisateurs sur les différents niveaux de processus. Le
paragraphe suivant porte sur la gestion du processus métier ou Business
Process Management (BPM).
Mayyad JABER 30
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
3.2.3 Business Process Management
L’enjeu du BPM est d’unifier, avec un seul outil, tous les moyens exigés
pour fournir à l’entreprise la possibilité de définir ses processus au
niveau métier. En plus, le BPM permet de faire intervenir les utilisateurs
et les applications de l’entreprise en tant que parties de ces processus.
L’objectif est de permettre aux décideurs, analystes métiers, équipes
fonctionnelles et équipes techniques de collaborer pour la définition et
l’évolutivité des processus métiers. Cela est rendu possible avec un seul
outil (BPM) qui agrège les différentes visions du processus métier. Le
processus métier est modélisé en couches (généralement au nombre de
trois) [BPMI, 2007]:
Le niveau métier : cette vue métier est une vue de haut niveau sur le
processus, définissant ses étapes principales et l’impact sur
l’organisation de l’entreprise. Ce niveau est défini par les décideurs
(directeurs) et les équipes méthodes de l’entreprise.
Le niveau fonctionnel : c’est la formalisation des interactions entre
les participants fonctionnels du processus. Dans cette vue, les règles
métiers sont formalisées afin de conditionner l’organisation du
processus afin de garantir que le résultat issu de son déroulement (à
la fin de la phase d’exécution) est conforme avec l’objectif métier.
Ce niveau est modélisé par les équipes fonctionnelles.
Le niveau technique : Il représente les liens entre les
activités/participants modélisés au niveau fonctionnel et les
applications/services du système d’information, ainsi que les tâches
utilisateurs. Ce niveau est mis en œuvre par les concepteurs du
système d’information et les équipes techniques de l’entreprise.
La stratégie d’un BPM se base entre autres sur les applications
du système d’information patrimonial : le mot d’ordre est la
réutilisabilité des applications de l’entreprise comme des composants
supports pour le processus métier. Dans notre chemin vers un système
d’information interentreprises, il faut traiter les outils et les techniques
permettant à la fois la modélisation et l’automatisation de l’exécution du
processus métier. Dans le modèle de processus métier illustré par la
Mayyad JABER 31
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 3-1, on constate que la notion de la logique d’assemblage ne peut
pas être représentée. La technique utilisée afin de modéliser cet aspect
est le Workflow. Cette technique issue du domaine de l’automatisation
du travail de bureau a été adaptée à partir des applications industrielles
comme un outil de base pour l’automatisation de processus métier
[Aalst, 2000, BPMI, 2007].
3.3 Le Workflow
Le Workflow est une technologie fournissant des facilités pour gérer,
coordonner et contrôler les activités dans une entreprise. Le Workflow
est un moyen de modélisation et d’exécution pour les processus métiers.
Selon le WfMC (Workflow Management Coalition), le Workflow est
l’automatisation totale ou partielle de l’exécution de processus métier,
exécution au cours de laquelle des documents, des informations et des
tâches passent d’un participant à un autre pour exécuter des actions
précises selon des règles prédéfinies [Dittrich and Tombros, 1999],
[WfMC, 2007].
Dans cette phase de notre travail, nous nous somme intéressés à
l’exploitation des techniques du Workflow pour la modélisation des
processus métier. Dans une deuxième étape, nous essayerons d’adapter
cette technologie afin de représenter les processus communs dans le
contexte de la chaîne logistique. Dans le domaine de la chaîne
logistique, un processus commun est un regroupement de processus des
différentes entreprises partenaires dans un environnement très
dynamique. Pour ce faire, la technologie de Workflow doit être adaptée
afin de traiter les processus commun qui sont à la fois susceptibles de
changements et distribués au travers les frontières des partenaires.
La technologie de Workflow a été largement adaptée dans les
environnements industriels avec des systèmes hétérogènes. Pour garantir
l’interopérabilité, il faut recourir au développement des standards.
3.3.1 WfMC et le modèle de référence pour le Workflow
Fondé en 1993, le WfMC est un organisme international sans but
lucratif. Le WfMC regroupe les vendeurs, les utilisateurs, et les
concepteurs de systèmes de Workflow ainsi que des équipes de
Mayyad JABER 32
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
recherche travaillant autour du Workflow. La mission de cette coalition
est de propager l’utilisation du Workflow. Leurs efforts sont orientés
vers la standardisation de la terminologie utilisée dans les logiciels,
l’interopérabilité et la connectivité entre les différents produits de
Workflow.
Le modèle de référence pour le Workflow a été développé à
partir d’une structure générique. Ce modèle identifie les interfaces dans
cette structure permettant l’interopérabilité entre les différents produits
de Workflow. Les composants de base et les interfaces du modèle de
référence pour le Workflow sont illustrés dans la Figure 3-2.
Figure 3-2 Modèle de référence pour le Workflow [Hollingsworth, 1995]
La coalition a également développé un cadre pour établir des
standards basés sur ce modèle. Ce cadre inclut cinq catégories de
standards (interfaces) pour l’interopérabilité et la communication entre
divers produits de Workflow : [Hollingsworth, 1995]
Interface 1 : inclut un méta-modèle commun pour décrire la définition
du processus et une grammaire textuelle pour l’échange de ces
définitions : WPDL (Workflow Process Definition Language). De plus,
cette interface inclut les APIs (Application Program Interface)
Mayyad JABER 33
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
nécessaires pour la manipulation des données de la définition du
processus.
Interfaces 2 et 3 : spécifient les APIs standards pour le management du
Workflow qui peuvent être contenus par les produits du WFM
(Workflow Model). Ces APIs proposent une méthode cohérente pour
l’accès aux fonctions de WFM via les moteurs des différents produits de
WFM.
Interface 4 : fournit une spécification résumée qui définit la
fonctionnalité exigée pour supporter l’interopérabilité entre les
différents moteurs de Workflow.
Interface 5 : spécifie les informations qu’il faut acquérir et enregistrer à
partir des événements qui ont lieu pendant la construction du Workflow.
Ainsi, l’interopérabilité au niveau organisationnel peut être
garantie en se basant sur ces différentes interfaces. Pour la suite et afin
de donner une vision plus claire sur l’application de la technologie de
Workflow dans le domaine de la chaîne logistique, nous allons présenter
les formes de base pour l’association des activités afin de construire un
processus métier dans un contexte de Workflow.
3.3.2 Modélisation du Workflow
L’enjeu essentiel du Workflow comme outil de modélisation de
processus métier est d’apporter les réponses aux questions suivantes :
quelles sont les activités (sous processus) à exécuter, dans quel ordre
l’exécution aura lieu, et quelles sont les informations échangées entre
ces activités.
Afin de satisfaire ces exigences, le Workflow utilise différents
types d’association pour réaliser la liaison entre les sous-processus dans
un processus métier : [Dittrich and Tombros, 1999], [Aalst, 2000]
Séquence : un sous-processus est lancé à la fin du sous-processus
qui le précède
Division Parallèle : c’est un point dans le processus métier où
l’exécution d’un processus (thread) se divise en plusieurs entités,
permettant l’exécution simultanée de ces threads.
Mayyad JABER 34
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Synchronisation : c’est un point dans le processus métier où
plusieurs sous-processus convergent dans un seul processus ce qui
entraîne la synchronisation des processus amonts.
Choix exclusif : c’est un point dans le processus métier où l’une des
branches d’un thread est choisie selon une décision de plus haut
niveau ou selon les données de contrôle du Workflow.
Fusion : c’est un point de fusion sans synchronisation pour plusieurs
threads.
D’autres types d’association pour les activités (sous processus)
de business peuvent être développés afin de satisfaire les exigences de
modélisation pour les règles de business dans le modèle physique du
processus métier [White, 2004].
Comme nous l’avons mentionné, notre objectif de l’application
de la technologie de Workflow est son utilisation pour la construction
d’un système d’information global dédié pour la gestion de la chaîne
logistique. Le Workflow se base sur la notion de modèle de processus.
L’usage d’une méthode basée processus comme ARIS est donc
souhaitable.
3.3.3 ARIS
ARIS (ARchitecture of Information System), est une approche orientée
métier pour la modélisation de l’entreprise. Elle fournit des facilités
pour la gestion de processus métier tout au long du cycle de vie, à partir
de l’ingénierie organisationnelle, jusqu’à l’implémentation du système
d’information correspondant.
L’approche ARIS représente une solution pour la construction
d’un système d’information à base de processus métier. En revanche,
cette approche n’offre pas de solution directe pour faire face aux
problèmes du traitement des processus métiers distribués, tel que le
processus métier commun de la chaîne logistique.
Cette méthode offre également des moyens pour l’amélioration continue
des processus métier. La Figure 3-3représente les quatre niveaux de
modélisation pour l’entreprise via des processus métier [Scheer, 1998],
[Scheer and Nuttgens, 2000] :
Mayyad JABER 35
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
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. D’ailleurs, des méthodes diverses sont
disponibles pour l’optimisation, l’évaluation et la garantie de qualité des
processus métier.
Figure 3-3 Architecture ARIS pour le processus métier [Scheer, 1998]
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 capaci té et
l’analyse de coût. Le monitoring des processus métier permet aux
managers de processus de garder un œil sur son état.
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.
Mayyad JABER 36
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Niveau 4 : systèmes d’application
Les documents livrés à un poste sont traités de manière spécifique. 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.
Avant de continuer notre étude concernant l’organisation de
processus métier distribués, nous allons montrer les avantages de la
technologie de Workflow sur l’organisation du processus métier.
3.3.4 Les avantages de la technologie de Workflow
Les systèmes de gestion de Workflow (Workflow Management Systems
– Gestionnaire de Workflows) regroupent des principes, des
méthodologies et des technologies issues de différents domaines
informatiques et des sciences du management. Au plan opérationnel, la
palette technologique recouvre le management des bases de donnée, la
technologie client serveur, l’informatique distribuée, les interfaces
graphiques (ou GUI, Graphical User Interfaces), l’intégration des
applications et des sous-systèmes, la messagerie, le management de
documents, la simulation, etc. Les points suivants résument les
avantages de cette technologie : [Bussler, 2001], [Aalst, 2000]
Le processus métier est explicitement défini. Par ce biais, les
responsabilités et les relations de coordination sont clairement
déterminées.
L’optimisation des processus métier peut être envisagée grâce à leur
définition explicite.
Les processus métier sont modulaires, ces modules peuvent être
réorganisés par le Gestionnaire de Workflow pour construire un
nouveau processus métier afin de réagir rapidement face aux
changements imprévus des exigences et des conditions de business.
Le Gestionnaire de Workflow peut tracer les opérations en temps
réel.
Le Gestionnaire de Workflow intègre les applications de différentes
plateformes dans un seul processus métier.
En se basant sur ces facilités des systèmes de gestion de
Workflow, nous allons détailler une vision intégrée du processus métier
Mayyad JABER 37
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
distribué. Cette vision nous sera très utile dans le développement de
l’architecture cadre visé.
3.3.5 Organisation du processus métier en sous-flux
Selon la structure hiérarchique du processus décrite dans la Figure 3-4,
un processus peut être organisé en sous-flux. Ainsi, une tâche peut
représenter beaucoup de sous-processus alternatifs internes ou externes.
Cette architecture présente les avantages suivants [Jaber, 2004] :
Figure 3-4 Construction du processus commun à partir de sous-processus
La définition du processus principal sera beaucoup plus simple (vue
synthétique).
Les sous-processus sont liés dynamiquement lors de l’exécution du
processus principal et non pas au moment de la conception de ce
processus. Ceci permet de cumuler les avantages du Workflow et de
l’EAI dynamique.
Nous utilisons ce modèle de processus décomposé en sous-flux
afin de représenter le processus interentreprises dans notre architecture
cadre visée. Cette approche d’attache dynamique des sous-processus
offre les avantages suivants :
La définition du processus est beaucoup plus simple.
Mayyad JABER 38
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
La réutilisation de la définition du processus fréquemment utilisé est
notamment améliorée.
Des parties de définition de processus métier peuvent être omise à partir
de la définition du processus principal.
La reconfiguration facile de sous-processus.
Une sélection facile des sous-processus appropriés lors de l’exécution
parmi de nombreux sous-processus internes ou externes. Ceci améliore
la hiérarchisation et la flexibilité.
Nous traiterons dans la suite les notions liées à la technologie
utilisée pour l’implémentation du processus métier.
3.3.6 Processus métier et Workflow dans le e-business
Le développement actuel de l’Internet et de l’informatique distribuée a
permis aux entreprises de conduire leurs affaires communes
électroniquement. Ceci a permis au e-business de voir le jour. Le terme
e-business a évolué en passant par les paradigmes suivants : [Bakos,
1998]
EDI (Electronic Data Interchange) l’enjeu de l’Echange de Données
Informatisé est de transférer d’application à application, à l’aide
d’ordinateurs connectés sur un ou plusieurs réseaux, des données
structurées selon un langage normalisé. Ce type de e-business
représente les premiers pas vers l’automatisation du processus
d’échange de l’information entre des entités de business séparées
géographiquement. Pour plus d’information sur les principes d’EDI
voir la section 4.2.1.
E-commerce : les distributeurs vendent leurs produits via les sites
web. Dans ce cas-là, les portails électroniques jouent le rôle de
façades frontales qui assurent les activités commerciales entre
l’entreprise et ses clients.
Le B2B e-commerce : il s’agit d’une communauté virtuelle de
partenaires ayant des intérêts communs et disposant des services
nécessaires pour atteindre au mieux leurs objectifs.
Afin de garantir la réussite d’un tel système de coopération, il
faut que l’organisation virtuelle bénéficie des ressources des partenaires
Mayyad JABER 39
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
en les exploitant de manière collaborative. Le processus métier et les
services fournis par les systèmes d’information des participants sont des
ressources importantes qui doivent être regroupées pour pouvoir piloter
ce système coopératif. Pour ce faire, la technologie de Workflow joue un
rôle crucial en fournissant des facilités pour gérer, coordonner et
contrôler les activités inter-organisationnelles. Le gestionnaire de
Workflow est un moyen efficace de modélisation mais aussi d’exécution
pour les processus métiers.
Selon le WfMC (Workflow Management Coalition), le
processus métier est un groupe d’activités qui réalisent collectivement
un objectif de business dans un contexte organisationnel. Le Workflow
est l’automatisation totale ou partielle de processus métier (BP). Le
Gestionnaire de Workflow permet de définir, créer et gérer l’exécution
de Workflow. Lors de l’exécution d’un Workflow des documents, des
informations et des tâches passent d’un participant à un autre pour
exécuter des actions précises selon des règles prédéfinies.
Le rôle essentiel de l’application de la technologie de
Workflow dans le domaine de la chaîne logistique est d’assurer le
processus de l’échange de l’information entre les partenaires. Le
paragraphe suivant porte sur cette notion.
3.3.7 Webflow
Le Webflow est une solution ajustable basée sur le web pour organiser
et supporter l’enchaînement des échanges de documents entre les
Workflows. Il forme un support d’échange informatisé pour améliorer le
déroulement du processus métier. Ces dernières années les systèmes
basés sur le Workflow ont souvent retenu l’attention pour être mis en
œuvre en tant qu’outils pour automatiser en premier lieu la gestion de
processus métier et ensuite la coopération entre entreprises. Dans le
cadre d’une chaîne logistique, la plupart des systèmes de Workflow se
focalisent sur les services de messagerie entre les partenaires. Cette mise
en œuvre manque sérieusement de facilités dans le domaine de gestion
de documents [Weber et al., 1998].
Le Webflow est conçu afin de fournir un cadre de Workflow
basé sur le web pour mettre en application des solutions orientées
gestion de processus métier. Le cadre fournit l’infrastructure pour la
Mayyad JABER 40
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
programmation des tâches et la construction du processus métier. Il est
particulièrement puissant pour automatiser les processus (y compris la
génération des documents) qui incluent des documents et courriers
(lettres) produites dynamiquement ainsi que des documents
normalement exigés dans le domaine de la chaîne logistique.
En vue d’adapter la technologie de Workflow aux besoins de la
chaîne logistique, il est indispensable de fournir des moyens afin de
coordonner de manière cohérente les processus des différentes
entreprises partenaires et ce dans un environnement dynamique. La
technologie de management de Workflow doit ainsi être capable de
traiter l’exécution des Workflows qui sont à la fois susceptibles d’être
modifiés et distribués entre les partenaires. Pour cela nous allons
présenter une étude détaillée de l’organisation du processus commun.
Plus particulièrement, nous mettrons l’accent sur les notions concernant
l’assemblage de processus distribués permettant de construire le
processus commun.
3.4 Organisation des processus distribués
Afin de construire un processus entre entreprises, chaque participant
doit adapter non seulement ses processus internes (processus privés),
mais également son comportement externe (processus publics). Une
définition d’un processus public peut être l’exécution d’un échange
formel de messages de sorte que les messages puissent être échangés
avec d’autres entreprises dans un ordre prédéfini et avec des formats
prédéfinis au travers de réseaux de communication [Bussler, 2001]. Les
processus publics de deux entreprises doivent s’interfacer afin de
permettre aux processus interentreprises de fonctionner. Par exemple, si
une entreprise envoie un ordre d’achat (OA) via un réseau donné, l’autre
entreprise doit pouvoir recevoir cet OA dans le format utilisé pour
l’envoi et en utilisant le même réseau. Cet assemblage de processus
publics peut être obtenu grâce aux protocoles B2B. Une fois qu ’une
entreprise a défini ses processus publics, ils doivent être contrôlés. Ceci
inclut la publicité (comment rendre des processus publics disponibles et
en quel langage formel), la découverte (comment trouver des entreprises
avec des processus compatibles), la sélection (quelle est l’entreprise à
contacter), la surveillance (quel est l’état d’exécution de ces processus
Mayyad JABER 41
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
public), ainsi que les contrats (comment établir une liaison légale entre
les entreprises, relation basée sur les processus publics). Pour ce faire,
un modèle commun d’intégration pour assembler les processus publics
dans un processus commun est indispensable.
3.4.1 RM-ODP : modèle d’intégration
Lorsque les entreprises coopèrent dans une chaîne logistique, elles
exigent une compréhension commune sur leurs processus métiers
publics. Pour cela un modèle d’intégration commun est nécessaire pour
rendre les processus d’entreprise visible et permettant leur
implémentation au niveau opérationnel. Nous proposons d’utiliser le
modèle RM-ODP (Reference Model for Open Distributed Processing).
RM-ODP est une norme ISO pour la description d’un processus commun
demandant la mise en œuvre de systèmes supports hétérogènes
[Naumenko et al., 2001]. Cela est effectué par la mise en œuvre d’un
modèle d’interaction commun.
RM-ODP définit cinq points de vue. Un point de vue (sur un
système) est une abstraction qui permet d’obtenir une spécification de
l’ensemble du système selon un aspect particulier. Les cinq points de
vue définis par RM-ODP sont à la fois simples et complets et couvrent
tous les domaines de la conception architecturale. Ces cinq points de vue
sont [Raymond, 1995]:
Le point de vue de l’entreprise : ce point de vue concerne
l’objectif, la portée et les politiques qui contrôlent les activités du
système spécifié dans l’organisation dont il fait partie. Pour cela, il
est nécessaire de comprendre les objectifs généraux et les
responsabilités de l’organisation de l’entreprise. Les objectifs et les
responsabilités sont définis par un contrat. Le système apparaît
comme un ensemble d’objets représentant les entreprises. Chaque
objet joue un rôle précis au niveau du processus métier. Le
comportement de ces objets est spécifié en termes d ’objectifs et de
politiques. Les interactions entre objets représentent des transferts
ou des changements de responsabilité.
Le point de vue informationnel : ce point de vue met l’accent sur
la nature des informations traitées par le système et les contraintes
Mayyad JABER 42
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
sur l’utilisation et l’interprétation de ces informations. Le résultat est
un système de spécification qui est facilement compréhensible. Les
propriétés importantes du système sont explicitement déclarées et
non pas mises en œuvre directement. Ainsi la description
d’information est indépendante de la façon dont le système est
construit. Dans le domaine de chaîne logistique, il est souvent
nécessaire de vérifier la spécification de l’information afin que
l’implémentation d’une application distribuée soit possible. Ce
faisant, les systèmes patrimoniaux peuvent être réutilisés
efficacement.
Le point de vue informatique : il s’intéresse à la décomposition
fonctionnelle du système en un ensemble d’objets. Ces objets
interagissent via des interfaces permettant le partage du système. Les
objets sont des composants conçus pour avoir un couplage lâche
avec des interfaces définies. Ces objets peuvent être construits
indépendamment et être ensuite réparties sur un réseau. Dans ce
point de vue, il n’est pas nécessaire de spécifier l’emplacement d’un
objet mais, les interfaces et les méthodes d’appel à distance doivent
être explicitement définies. L’utilisation de ce point de vue dans le
cadre de l’intégration du processus commun offre aux partenaires la
possibilité de construire des services distribués par l’assemblage des
objets métiers.
Le point de vue de l’ingénierie : il se concentre sur l’infrastructure
nécessaire pour supporter le système de distribution. Plus
précisément, il est focalisé sur la façon dont le système est distribué
et configuré physiquement. Cela est réalisé en tenant compte de la
capacité de traitement, de la bande passante de l’infrastructure de
communication, de la transparence et de la qualité de service. Les
aspects sémantiques ne sont pas pris en compte dans le point de vue
de l’ingénierie.
Le point de vue technologique : ce point de vue porte sur le choix
de la technologie pour supporter la distribution du système. Pour
cela, il définit les technologies des objets qui composent le système.
Il réalise le lien entre l’ensemble des spécifications et la mise en
œuvre concrète. Par exemple, la technologie des services Web et les
protocoles associés tels que UDDI, WSDL, BPEL4WS [ShaikhAli et
al., 2003], pourraient être utilisés comme outils de facto pour la mise
Mayyad JABER 43
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
en œuvre d’un système de gestion de la chaîne logistique basé sur
SOA. Les choix techniques sont abordés en détail dans le Chapitre 4.
L’application du modèle RM-ODP comme un modèle
d’intégration permet aux entreprises de garantir la flexibilité du système
global. Les compagnies participantes doivent convenir d ’un accord
uniquement sur les processus publics. L’exécution des processus privés
est complètement indépendante des processus publics et chaque
entreprise peut contrôler ses processus privés indépendamment des
autres partenaires. La liaison entre le processus privé et les p rocessus
publics répond aux besoins d’isolation et d’indépendance. On notera que
la modification d’un processus privé pourrait exiger un changement de
cette liaison entre processus. Toutefois cette association étant au sein de
l’entreprise, elle n’affecte pas les processus privés des autres
partenaires. Afin de parvenir à l’assemblage formant le processus
commun, les paragraphes suivants portent sur les notions de processus
public, de processus privé et sur la liaison entre les deux.
3.4.2 Le processus public
Dans un protocole d’échange B2B, comme celui développé par
RosettaNet [RosettaNet, 2006], les activités sont normalement orientées
vers l’extérieur. Cette orientation vers l’extérieur est prise dans le sens
où l’accent est mis sur l’échange de messages entre les entreprises. Dans
ces conditions, un protocole de B2B n’est pas concerné par
l’implémentation des processus privés d’une entreprise. En général, les
concepts figurant dans les protocoles de B2B sont : [DiCaterino et al.,
1997], [Sadiq and Orlowska, 1999]
Le format de message : Le format de message définit le cadre du
contenu métier d’un message. Par exemple, chaque document à
échanger, comme un ordre d’achat (OA) ou une facture, est décrit dans
un annuaire globale et peut ainsi être généralisé comme un format de
base entre les partenaires.
L’envoi et la réception des messages : Les messages sont normalement
envoyés par une entreprise et reçus par une autre. Les processus d’envoi
et de réception des messages sont normalement déclenchés par des
Mayyad JABER 44
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
événements distincts dans les protocoles B2B. Ces événements
déterminent quand un message doit être reçu et quand un message doit
être envoyé. Les activités sont typées (en indiquant le type de message à
envoyer ou à recevoir). Ceci permet de vérifier si deux processus publics
de deux entreprises différentes peuvent être couplés.
Les messages métiers et les messages de confirmation : le premier
type de message contient le contenu de business tandis que l’autre type
contient des aperçus. Par exemple, un message de confirmation peut
servir à authentifier la réception d’un message métier.
La gestion des échecs : Les messages dans le domaine du B2B (comme
celui de la chaîne logistique) sont transmis au travers de réseaux parfois
peu fiables. La définition d’un délai d’attente sur les messages ainsi que
la définition d’une logique de réaction permet de traiter les échecs. Par
exemple, une contrainte de délai peut être fixée pour indiquer qu’un
message de confirmation doit être reçu dans un délai de deux heures
après l’envoi d’un message métier. Si aucun message de confirmation
n’a été reçu dans ce délai de deux heures, un mécanisme de traitement
de cette incohérence doit être lancé pour assurer le bon fonctionnement
du processus commun. Cela conduit à devoir définir un système de
gestion pour les transactions distribuées. Ce point sera abordé plus tard
dans ce chapitre.
Le contrôle et la suppression des duplications : Les protocoles de
B2B doivent également mettre en application le principe de transférer
les messages "seulement une fois". En raison de la logique de "délai
d’attente", un message pourrait être envoyé deux fois. Par exemple, dans
le cas où un message n’a pas été perdu mais où la confirmation était
tardive, le processus précédent peut être amené à renvoyer le message
initial. Dans ce cas, le message dupliqué doit être éliminé.
Les rôles : un processus public dans un protocole de B2B possède deux
facettes, une pour l’entreprise (localement) et l’autre pour le monde
externe. Les partenaires impliqués dans un même processus commun
doivent avoir un comportement compatible avec le protocole de B2B,
c’est-à-dire qu’on doit avoir la séquence de messages prévue, que les
formats de ces messages soient corrects et que les messages générés par
un partenaire soient pris en compte par l’autre. Pour ce faire, la
définition des processus publics doit prendre en compte les différents
Mayyad JABER 45
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
rôles possibles pour les entreprises participantes comme par exemple un
rôle d’acheteur, de vendeur, de transporteur, etc.
Un exemple de processus public simple associé au rôle d’un
acheteur, est illustré dans la Figure 3-5. Il détermine les messages à
échanger et la séquence d’échange. Ce processus envoie un ordre
d’achat (OA) et attend une confirmation de bonne réception de cet OA
par un message d’aperçu (APRÇ). Il attend ensuite un message de
validation pour son ordre d’achat puis il renverra un aperçu à son tour.
Les activités de connexion sont utilisées pour réaliser la liaison avec les
processus privés.
Figure 3-5 Exemple de processus public
D’autres fonctionnalités sont indispensables pour les protocoles
de B2B afin de fournir l’intégralité des moyens nécessaires pour
l’échange de données informatisées. Les protocoles de transport, comme
HTTP, sont indispensables pour supporter l’échange de messages entre
les entreprises participantes. De même, il faut introduire une politique
de sécurité qui inclut des facilités de chiffrement/déchiffrement de
messages et de signature électronique [Aalst, 2000],[Jaber, 2004].
Mayyad JABER 46
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
3.4.3 Le processus privé
Comme nous l’avons déjà expliqué, l’objectif de notre travail est de
traiter les aspects liés à la construction d’un système coopératif entre
entreprises. Cela ne nous empêche pas de prendre en compte les détails
liés aux processus privés dans notre champ d’action. Nous citons ici les
notions de base à propos de ces processus. Pour décrire et modéliser les
processus privés, nous nous basons sur les concepts du Workflow.
L’application de la technologie de Workflow (pour la gestion de
processus privé) facilite de manière incontestable le processus de
l’externalisation des applications patrimoniales des entreprises
participant à la chaîne logistique. Un processus privé peut être défini en
s’appuyant sur les composants suivants [Oba and Komoda, 2001],
[WfMC, 2007] :
Les tâches du processus : Les tâches d’un processus métier
représentent les activités liées au déroulement du processus. Un
gestionnaire de Workflow définit de manière ferme les activités à
exécuter pendant l’exécution d’un processus de Workflow. Par
exemple, une tâche de vérification (pour valider un ordre d’achat
particulier) forme une tâche sous jacente du processus de traitement
de l’ordre d’achat.
Le flux de contrôle : Le flux de contrôle définit l’ordre dans lequel
les sous-processus seront exécutés. Par exemple, un processus
d’extraction d’un ordre d’achat est exécuté avant le processus de
validation qui précède à son tour l’exécution du processus consacrée
à l’envoi de « l’Ordre d’Achat Validé » (OAV) vers l’entreprise
concernée.
Le flux de données : Le flux de données définit comment les
données passent d’un sous-processus l’autre. Par exemple, l’ordre
d’achat OA est extrait de la base puis passé au processus de
validation et en fin transmis au sous-processus de Workflow
consacré à l’envoi des documents vers une entreprise de la chaîne
logistique.
En se basant sur la technologie de Workflow, les processus
privés au sein des entreprises peuvent être modélisés avec un niveau
satisfaisant de standardisation. Afin de garder la flexibilité de processus
Mayyad JABER 47
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
interentreprises, un processus de liaison entre les processus privés et
publics doit être défini.
3.4.4 La liaison
Puisque les processus publics sont orientés vers l’extérieur et que les
processus privés sont focalisés vers l’intérieur de l’entreprise, il est
nécessaire d’assurer leur liaison de manière flexible. Il s’agit de définir
un processus permettant l’interconnexion indirecte entre un processus
privé et un processus public afin de garantir leur indépendance vis-à-vis
du processus de ré-engineering imposé par l’évolution du système. Le
processus de liaison doit donc supporter l’échange de données (c’est-à-
dire permettre à des données de « sortir » de l’entreprise lorsqu’elles
sont envoyées aux partenaires et réciproquement être capable d’intégrer
des données venant de partenaires). Pour répondre à ce cahier des
charges, il faut ajouter des activités supplémentaires de connexion. Ces
activités de connexion sont des activités consacrées à la communication
entre les processus privés et les processus publics. Elles sont utilisées
dans les processus publics et dans les processus privés pour transporter
des messages d’un processus privé vers un processus public et vice-
versa. Dans un contexte de gestion de Workflow, ces activités de
connexion sont des processus de Workflow conçus avec le but unique de
faire communiquer les processus publics et privés [Hollingsworth,
1995].
La Figure 3-6 montre la liaison entre un processus privé
représentant un processus interne d’achat d’une entreprise et un
processus public qui échange les ordres d’achat (OA) et les aperçus
correspondants (comme nous l’avons déjà expliqué dans la Figure 3-5).
Les activités de connexion présentées ici sont typées et orientées :
chaque activité de connexion est liée à un type de message et peut traiter
seulement ce message. La direction de la connexion indique si le
message est envoyé du processus privé au processus public ou si c’est
l’inverse. Le processus privé est lié au système de management de
ressources de l’entreprise (comme le système d’ERP par exemple). De
l’extérieur, chaque entreprise voit que le message va être envoyé à un
processus privé mais n’a aucune visibilité sur le processus privé lui-
même. La liaison doit être assez flexible pour supporter les différences
Mayyad JABER 48
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
entre les processus privés et publics de telle manière que le processus
privé puisse rester inchangé vis-à-vis de différents processus publics.
Figure 3-6 La liaison entre deux processus, privé et public
3.4.5 Gestion du processus public
La construction des processus publics est seulement une étape pour
réaliser les processus communs de la chaîne logistique. Au préalable, il
faut trouver d’autres entreprises partenaires qui veulent s’engager dans
l’exécution de ces processus pour traiter leurs affaires commerciales.
Nous distinguons deux classes de partenaires commerciaux, la première
concerne des partenaires qui sont déjà "qualifiés" pour l’exécution de
processus interentreprises en utilisant des processus publics, et l ’autre
des partenaires qui désirent mettre en application de tels processus. Une
manière de trouver les partenaires pertinents est d ’annoncer
publiquement les processus publics et de faire découvrir ces processus
Mayyad JABER 49
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
aux autres entreprises du marché. Cette approche est communément
utilisée dans les organisations à base de services que nous présenterons
dans le chapitre suivant. Tout ce qui est impliqué par un environnement
public de publicité et de découverte est présenté ci-après :
La description de processus public : Une formule pivot est exigée
afin de rendre ces processus compréhensibles par les membres du
marché. Quelques propositions sont déjà disponibles comme
ebXML, RosettaNet, et WSDL [Tambag and Cosar, 2003]
[RosettaNet, 2006], [Curbera et al., 2002]. Les aspects techniques
liés à la description et l’implémentation du processus publique sont
abordés dans le Chapitre 4.
La publicité : Une fois que les processus publics sont définis, leur
définition doit être sauvegardée dans un endroit accessible par les
partenaires commerciaux potentiels pour offrir des facilités de
recherche. Ceci exige un endroit connu (publiquement) avec une
interface d’accès pour rechercher l’information sur ces processus :
UDDI permet de fournir un enregistrement public qui permet à une
entreprise de représenter ses processus publics alors que l’approche
en web EDI d’ebXML définit un mécanisme d’enregistrement
[UDDI, 2007], [Curbera et al., 2002].
L’exploration : Avec les fonctionnalités d’enregistrement public,
une entreprise peut naviguer dans ces bases « annuaires » et trouver
des processus publics adéquats, c’est-à-dire présentant une
possibilité pour établir l’exécution de processus entre entreprises.
Cependant, le fait que deux entreprises puissent échanger un ordre
d’achat ne signifie pas obligatoirement collaboration. Un détail
important est que les données commerciales échangées soient
semblables au niveau du processus métier. Par exemple, une
entreprise qui veut acheter des pneus doit trouver un fournisseur qui
vend des pneus. Ceci signifie qu’outre la description de processus
publics (comme l’échange des OAs) une ontologie métier doit être
attachée au processus public pour définir le contenu (des données)
des messages échangés afin de rendre l’identification complète (des
pneus sont vendus et pas des équipements pour vitres électriques
d’un véhicule).
La sélection : Si une entreprise trouve plusieurs partenaires
commerciaux potentiels grâce au processus de l’exploration, elle
Mayyad JABER 50
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
doit en choisir un. La sélection est habituellement basée sur les
qualités d’affaires plutôt que sur le fait qu’une entreprise peut
participer à l’exécution de processus entre entreprises. Cependant,
ces qualités comme la classification sur le crédit, la fiabilité, la
qualité de produits, ne sont pas disponibles publiquement. Le
processus de sélection comporte donc un certain travail manuel pour
choisir les partenaires commerciaux appropriés (comme l’échange
d’expérience avec les partenaires commerciaux existants)
[Chandrashekar and Schary, 2002].
La fiabilité : Durant l’exécution des processus publics, la qualité de
service est un aspect capital pour le succès. Les processus publics
doivent être exécutés complètement et suivre leur description.
Toutes les définitions de fiabilité et de sécurité doivent être suivies
de sorte que les partenaires commerciaux impliqués puissent sans
risque dépendre l’un de l’autre. On s’attend également à ce que les
partenaires commerciaux n’abusent pas des processus publics pour
le pollupostage (spamming) de leurs concurrents avec de faux
messages.
La surveillance : A un instant donné, les partenaires commerciaux
impliqués dans l’exécution de processus interentreprises peuvent
vouloir connaître le statut de la collaboration. Puisque les processus
publics sont communs, chaque partenaire commercial sait si l’autre
doit renvoyer un message ou si le partenaire en attend un. En outre,
chaque partenaire commercial connaît l’état de son processus privé à
un point quelconque du temps. Le seul cas plus compliqué est celui
où un partenaire commercial veut connaître l’état du processus privé
de l’autre partenaire commercial et où son partenaire lui en a conféré
le droit. Ceci peut être réalisé soit par un outil de surveillance qui
accède directement à l’environnement d’exécution du processus
privé selon des permissions spécifiées dans le système de sécurité
des partenaires commerciaux, soit en présentant un autre processus
public qui définit les messages de surveillance échangés. La dernière
approche est préférable puisqu’une entreprise peut décider quelles
informations concernant l’état de ses processus peuvent être
exposées ou non. Ceci est important pour conserver le savoir-faire
dans un environnement concurrentiel.
Mayyad JABER 51
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Les contrats : Une exigence fondamentale est qu’un contrat légal
soit mis en place avant que l’exécution de processus entre
entreprises ait lieu. Des mesures initiales sont prises par ebXML
pour définir les accords entre partenaires commerciaux, accords qui
définissent les messages qu’il est permis d’échanger [Oasis, 2001].
Dans ce qui précède, nous voyons que l’un des grands défis de
l’approche basée sur les processus publics est la sécurité. Si un
processus public est rendu disponible dans un registre pour
l’exploration, il ne devrait pas être possible d’envoyer immédiatement
un message à l’entreprise qui a exposé ce processus. En d’autres termes,
si les adresses des partenaires du réseau sont connues dès ce moment, il
serait facile de réaliser du pollupostage (spamming). Le défi ici est que
les adresses physiques nécessaires pour échanger des messages
efficacement (hors les démarches d’exploration bien entendu), ne soient
pas visibles jusqu’à ce qu’un contrat soit en place. Ceci permet d’éviter
l’abus d’utilisation du processus public.
Un autre grand défi pour la construction du processus commun
est la garantie de sa cohérence dans un milieu dynamique et peu stable
tel que celui de la chaîne logistique. En plus, le manque de fiabilité lié
aux réseaux de communication ajoute une contrainte supplémentaire sur
le déroulement du processus métier commun. A cet effet, nous
proposons de recourir à la gestion de transaction comme un outil de
contrôle pour assurer le bon fonctionnement du processus de la chaîne
logistique.
3.5 Systèmes distribués et transactions
Les systèmes distribués posent des problèmes de fiabilité qui ne sont pas
rencontrés fréquemment dans les systèmes centralisés. Un système
distribué partagé sur plusieurs ordinateurs (reliés par un réseau) peut-
être soumis à des défaillances de l’un de ses éléments, comme les
ordinateurs eux-mêmes, les systèmes d’exploitation, les connexions
réseaux ou les applications des entités individuelles. En outre, les
activités inter-partenaires peuvent avoir une durée d’exécution
indéterminée. La décentralisation permet à certaines parties du système
d’être en situation d’échec tandis que d’autres parties restent
Mayyad JABER 52
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
fonctionnelles. Cela conduit donc à un comportement anormal pendant
l’exécution des applications distribuées.
Quand il s’agit d’un processus commun interentreprises, une
sélection de services distribués sur plusieurs ordinateurs peut être
utilisée pour supporter son implémentation. En principe, un Workflow
qui utilise cette collection de services impose que cet assemblage se
comporte toujours de manière consistante, même en présence de
défaillances. Une exigence essentielle pour garantir la cohérence d’un
tel processus est celle dite de l’"atomicité" : soit la transaction se
termine normalement et donne les résultats prévus, soit elle est annulée
sans produire aucun résultat. Dans le cas d’une interruption, l’état du
système doit être rétabli dans un état stable prédéfini grâce à un système
de retour en arrière adapté.
Une transaction atomique se termine soit dans l’état "commis"
soit dans l’état "avorté" (annulé). Quand une transaction est
« commise », toutes les modifications liées à son exécution deviendront
durables. Lorsqu’une transaction est avortée, toutes les modifications
apportées par son exécution sont annulées. Le paragraphe suivant porte
sur la description des propriétés des transactions ACID, c’est-à-dire
atomicité, consistance, isolation et durabilité [Mammar et al., 2005],
[Stanford, 1997].
3.5.1 Les transactions ACID
Une transaction dite ACID (Atomicity, Consistency, isolation,
Durability) possède les propriétés suivantes :
Atomicité : La transaction se termine avec succès total (elle est dite
"commise"), ou si elle échoue, tous ses effets sont annulés.
Cohérence : La transaction produit des résultats cohérents et
préserve la stabilité de l’application globale (ex. le processus
commun de la chaîne logistique).
Isolation : Les états intermédiaires produits, tout au long l’exécution
de la transaction, ne sont pas visibles par d’autres transactions. En
outre, les transactions semblent être exécutées en série, même si
elles sont effectivement exécutées simultanément. Cela
généralement est réalisé par le verrouillage des ressources
impliquées pour la durée de la transaction. Ce verrouillage empêche
Mayyad JABER 53
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
les conflits potentiels issus de demandes d’accès simultanées
provoquées par plusieurs transactions.
Durabilité : Les effets d’une transaction "commise" ne sont jamais
perdus (sauf par une défaillance catastrophique).
Les systèmes de transaction traditionnels fonctionnent en deux
étapes pour garantir le bon fonctionnement d’un processus distribué
entre les participants. Au cours de la première étape dite "phase de
préparation", un participant doit maintenir les changements d’états, qui
ont eu lieu au cours de l’exécution de la transaction, de sorte que ces
modifications puissent être annulées ou « commises » ultérieurement,
une fois que l’état final de la transaction a été déterminé. Dans le cas où
aucune défaillance n’a eu lieu pendant la première phase, la deuxième
phase dite "phase de commit" vise à remplacer l’état d’origine avec
l’état issu de l’exécution de la transaction. Dans ce cas, les changements
au cours de la première phase deviendront durables.
3.5.2 Le rôle des transactions dans le processus métier commun
La plupart des Workflows et des applications de type B2B nécessite le
support de systèmes de gestion de transactions afin de parvenir à un
résultat mutuellement validé par les partenaires. Le support
transactionnel assure la consistance des résultats pour l’ensemble des
tâches au sein du processus commun. En outre, la plupart des processus
métiers collaboratifs imposent de traiter la complexité due à la longue
durée d’exécution. Cela implique de disposer d’un mécanisme
d’annulation des tâches qui sont déjà terminées mais qui nécessitent de
procéder au recouvrement "rollback".
Les résultats d’un sous-processus sont généralement mis à
disposition avant que le processus global soit achevé. Par exemple, un
système de réservation des compagnies aériennes peut réserver un siège
pour un passager pendant un délai précis. Si le passager ne confirme pas
la place avant l’expiration du délai, elle sera récupérée pour un autre
passager. La gestion des échecs susceptibles de survenir au cours de
l’exécution d’un processus commun impose la mise en œuvre d’un
système de traitement des transactions distribuées.
Mayyad JABER 54
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le blocage statique de ressource (le siège dans notre exemple)
rend difficile, voire impossible, l’intégration des architectures
traditionnelles de gestion de transaction dans un tel environnement
dynamique de B2B. En outre, les contraintes d’interopérabilité des
systèmes de traitement des transactions représentent un élément
important à prendre en compte pour le domaine du B2B. Les
applications de type B2B impliquent habituellement la connexion des
systèmes dorsaux (back-end systems), soit directement, soit
indirectement. La possibilité de lier l’ensemble des transactions des
partenaires avec leurs environnements hétérogènes est la clé du succès
de la gestion de transactions distribuées.
3.5.3 X / Open DTP
Le modèle X/Open DTP (Distributed Transaction Processing) est une
architecture logicielle permettant à plusieurs applications de partager
des ressources fournies par de multiples managers de ressources
(Resource Manager). Cela est possible du fait de l’intégration des
différents processus transactionnels dans une transaction globale afin de
coordonner les tâches [X/Open, 1996].
Le modèle X/Open DTP comprend cinq composantes
fonctionnelles (Figure 3-7) :
Figure 3-7 Modèle X/Open DTP [Stanford, 1997]
Mayyad JABER 55
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le programme d’application (AP), qui définit les limites de la
transaction et précise les actions qui constituent une opération .
Les managers de ressources (RM) comme les bases de données ou
les systèmes d’accès aux fichiers sont les systèmes qui donnent
l’accès aux ressources.
Le Manager de Transaction (TM) assigne des identifications aux
processus, contrôle leur progrès, et assume la responsabilité de
l’aboutissement de transaction et de la coordination de recouvrement
en cas d’échec.
Les managers de communication de ressources contrôlent la
communication entre les applications réparties à l’intérieur ou à
travers les domaines du TM.
Un protocole de communication offre les services de communication
sous-jacents utilisés par les applications distribuées et supportées par
les managers de communication de ressources.
X/Open DTP est une norme de traitement des transactions
distribuées basée sur un protocole de validation (commitment) en deux
phases. Plus particulièrement, l’architecture définit les interfaces de
programmation d’applications (APIs) et les interactions entre les
applications transactionnelles (AP), les managers de transactions (TMs)
et les managers de ressources (RMs).
Au sein de la chaîne logistique, le traitement des transactions
distribuées doit fournir un mécanisme efficace pour combiner plusieurs
processus dans un seul processus coopératif. Le processus résultant doit
maintenir la cohérence des ressources partagées à travers des processus
distribués. L’interopérabilité des composants dédiés à la gestion de
transaction impose de mettre en place un système de gestion de
transaction globale. Dans le cadre de processus liant différents sous-
processus, cette architecture manque d’agilité. En effet, les composants
proposés par X/Open DTP pour la gestion de transactions distribuées
sont configurés de manière fixe. Cela impose un problème au niveau de
granularité concernant les différents services susceptibles de participer
dans un processus interentreprises. Ceci impose de définir une solution
dédiée pour la gestion de transactions distribuées dans un environnement
orienté service dans le contexte du B2B. Ce point sera détaillé dans la
section 4.5.3.
Mayyad JABER 56
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
3.6 Conclusion
Dans une chaîne logistique, chaque partenaire possède son propre
système d’information patrimonial utilisé pour supporter les processus
locaux. Puisque les systèmes patrimoniaux sont souvent des systèmes
hétérogènes, une infrastructure interopérable doit être établie pour
mettre en œuvre des processus métiers distribués. Cette interopérabilité
implique que les partenaires doivent se mettre d’accord sur les mêmes
techniques d’exposition et de gestion pour les ressources partagées.
Nous distinguons l’intégration au sein de la chaîne logistique d’une
étroite intégration de deux ou plusieurs systèmes d’information. Dans ce
dernier cas, les approches des technologies de l’information sont
focalisées sur le développement d’un système dit intergiciel
(middleware) qui conduit à un système étroitement couplé. Au contraire,
les chaînes logistiques sont des organisations temporaires qui exigent
que leurs systèmes d’information soient lâchement couplés.
Une approche fondée sur un Workflow de type B2B peut être
obtenue à partir d’un système de type EDI traditionnel (Electronic Data
Interchange) ou bien d’un environnement de e-buisness. À cette fin,
Aalst [Aalst, 2002a] propose des descriptions multiples pour les
processus métiers partagés : des Workflows publics et privés (sections
3.4.2 et 3.4.3) sont définis concurremment et la cohérence globale est
réalisée grâce aux formats d’échange d’informations bien définies
[Bussler, 2002]. En tenant compte de la technologie de Workflow
permettant l’échange d’information interentreprises, nous allons
présenter les techniques permettant d’intégrer les systèmes
d’information supportant les processus métiers. Nous nous intéressons
d’abord à l’état de l’art de systèmes patrimoniaux dans le contexte de la
chaîne logistique. Nous abordons ensuite les notions concernant
l’intégration de systèmes patrimoniaux et notamment le manque
d’interopérabilité entre ces systèmes.
Mayyad JABER 57
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 4 Systèmes d’information
distribués
4.1 Introduction
L’organisation du système d’information d’une entreprise est basée sur
divers logiciels permettant de gérer les activités liées aux différents
composants du processus métier. Dans le Tableau 2-1, nous avons cité
quelques systèmes support des systèmes d’informations d’entreprise
utilisables pour la gestion du processus métier dans le contexte de la
chaîne logistique. Ce sont des systèmes comme les systèmes d’ERP
(Enterprise Resource Planning), de WMS (Warehouse Management
Systems) et de TMS (Transportation Management Systems). Il s’agit de
progiciels (ou plus rarement de logiciels spécifiques) fournissant des
fonctions standardisées pour des utilisations et des utilisateurs tout aussi
"standard".
Les systèmes patrimoniaux se concentrent sur les processus
internes de chaque entreprise participante. Leurs bases de données
contiennent des informations propres à l’entreprise (informations
internes) [Borges et al., 2005]. Ces logiciels fournissent à la fois les
moyens pour la collaboration dans chaque entreprise et des interfaces
utilisateurs pour les acteurs internes. Ceci impose donc de recourir à des
systèmes supplémentaires pour supporter la coordination inter-
organisationnelle.
En effet, ces systèmes ne permettent pas de gérer les processus
communs de la chaîne logistique : du fait de leur organisation (serveurs
centraux et logiciels « procéduriers »), ils ne possèdent pas la flexibilité
exigée par un réseau d’entreprises. En revanche, cette flexibilité est
offerte par la structure de systèmes locaux liés via les interfaces des
systèmes d’EDI (Electronic Data Interchange). Toutefois, ces derniers
Mayyad JABER 58
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
sont dédiés à l’échange de données et non aux règles de décision dont on
a besoin pour gérer la chaîne de partenaires. Ceci impose donc la mise
en œuvre d’un système pilote pour la chaîne globale, système qui non
seulement facilite l’échange de données entre partenaires, mais aussi
offre les moyens pour coordonner les activités distribuées entre les
entreprises participantes afin de former un support d ’aide à la décision
globale.
Plusieurs contraintes doivent être prises en compte dans la
conception de la structure d’un tel système distribué. D’abord et avant
tout, beaucoup d’investissements sur les systèmes patrimoniaux ont déjà
été réalisés par les entreprises. Ceci implique donc une première
contrainte : le principe de recommencer à zéro est inapplicable. La
structure visée doit donc utiliser les systèmes patrimoniaux comme
briques de base. Par ailleurs, compte tenu de la nature temporelle de la
coopération entre les partenaires, la structure recherchée doit être
dynamique, c’est-à-dire qu’elle n’est valable que pour une durée limitée,
liée à la réalisation d’un objectif précis et avec un minimum de
coordination verticale. Du point de vue fonctionnel, chaque entreprise
doit être capable de maîtriser l’accès à ses informations en gardant un
niveau sécurité important pour protéger ses savoir-faire et les
informations liées à un avantage compétitif. Il faut donc définir une
politique de sécurité globale pour l’ensemble des activités entre
partenaires. Cette politique doit être définie et maintenue en termes
contractuels sous forme de contrats électroniques.
4.2 Intégration et échange : techniques existantes
Dans la suite, nous allons traiter des notions liées à l’intégration et
l’échange de données entre les systèmes d’information distribués au sein
de l’entreprise. L’objectif est de montrer la possibilité de se servir des
techniques existantes pour la mise en œuvre du système d’information
interentreprises visé. Nous introduirons l’EDI (Electronic Data
Interchange) ou, en français, Echange de Données Informatisées. L’EDI
offre un moyen pour échanger les informations entre des entités de
business séparées géographiquement. Ensuite nous présenterons les
technologies d’EAI (Enterprise Application Integration) et CORBA
(Common Object Request Broker Architecture). En effet, CORBA peut
Mayyad JABER 59
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
servir comme un middleware dont l’objectif est de regrouper des
applications réparties par l’intermédiaire d’un bus général de
communication. Les détails des ces techniques sont traités dans les
paragraphes suivants.
4.2.1 Premiers pas : l’EDI
L’EDI peut être défini comme l’échange, d’ordinateur à ordinateur, de
données concernant des transactions en utilisant des réseaux et des
formats normalisés. Les informations issues du système informatique de
l’émetteur transitent par l’intermédiaire de réseaux vers le système
informatique du partenaire pour y être intégrées automatiquement. Ceci
induit le traitement des points suivants [Webster, 1995] :
Echanger quoi ? il faut s’entendre sur ce qu’on échange et comment
le modéliser.
Echanger comment ? il faut transporter les informations via un
média et des protocoles de communication donnés.
Echanger pourquoi ? garantie sur les processus des deux côtés.
Un des défauts de l’EDI est son coût assez élevé, lié au besoin
d’une infrastructure de réseau adaptée et à l’organisation de processus
contraignant avec des interfaces « lourdes ». Ce défaut peut être évité
avec la technologie du web EDI que nous présentons dans le paragraphe
suivant.
4.2.2 Web EDI
Dans sa forme la plus simple, le Web EDI permet aux petites et
moyennes entreprises de créer, gérer, recevoir et envoyer des documents
électroniques en utilisant des technologies et outils du Web [Fu et al.,
1999]. Pour cela, un service dédié doit transformer de façon transparente
les données de l’entreprise en format échangeable (respectant un
standard EDI) et les transmettre aux partenaires commerciaux. Des
formats simples sont utilisés pour permettre aux entreprises d’échanger
avec leurs partenaires commerciaux. En utilisant une interface web
convenable, les transactions de type EDI peuvent être effectuées aussi
facilement par le biais du courrier électronique. Le Web EDI permet
Mayyad JABER 60
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
également de recevoir et d’envoyer des documents métier sans recourir à
un logiciel particulier. L’avantage du Web EDI est le fait qu’il est
accessible partout dans le monde sans avoir besoin d’installer des
logiciels métiers ou de mettre en place une infrastructure de
communication particulière.
Le Web EDI offre un moyen efficace pour échanger les
données entre partenaires. En revanche, comme l’EDI classique, il n’a
pas trouvé la reconnaissance méritée dans le domaine du business inter -
organisationnel. Cela dû au fait qu’il est dédié à l’échange de données et
non aux règles de décision, règles dont on a besoin pour gérer la chaîne
de partenaires.
4.2.3 Communication entre les briques logicielles : EAI et CORBA
Comme nous l’avons déjà mentionné, les systèmes d’information
d’entreprise sont composés de plusieurs "briques applicatives ". Souvent
développées indépendamment et recourant à des technologies parfois
incompatibles, ces outils ne sont que peu interopérables. Dans une
logique d’intégration (ou tout au moins de couplage entre ces briques), il
convient d’ajouter des systèmes intermédiaires qui facilitent la démarche
d’interfaçage, voire d’intégration. C’est le rôle des outils d’EAI
(Enterprise Application Integration). Outre la gestion des formats
d’échange, l’EAI doit aussi prendre en compte le flux des événements
entre les applications. Dans ce contexte, un système de gestion de
Workflow devient un élément important de l’EAI, car il est capable de
coordonner et de contrôler le flux des évènements entre les applications.
Ceci conduit donc à définir un type particulier d’EAI : l’EAI basé sur le
Workflow. Les systèmes de ce type peuvent être classés en deux
catégories [Kwak et al., 2002] :
EAI statique : L’exécution du processus de Workflow suit un chemin
précis et prédéfini. Il n’est pas possible d’ajouter un processus ou de
modifier la configuration de la définition du processus en cours
d’exécution.
EAI dynamique : La liaison enter les services des applications se fait
en cours d’exécution selon des règles spéciales. La configuration des
interfaces des services peut alors être changée et de nouveaux systèmes
peuvent être ajoutés.
Mayyad JABER 61
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
L’EAI permet de résoudre le problème d’interopérabilité entre
les briques applicatives constituant les applications propres à
l’entreprise. Elle permet de spécifier les informations à échanger mais
avec une localisation statique de ces informations. En revanche, et en se
basant sur les facilités de CORBA, un middleware générique peut être
mise en place permettant d’accéder aux informations quelle que soit leur
localisation.
CORBA (Common Object Request Broker Architecture)
représente une solution d’intégration pour des applications développées
indépendamment [Vinoski, 1997]. Il s’agit d’un middleware orienté
objet proposé par l’Object Management Group (OMG). L’OMG est un
consortium international créé en 1989 et a pour objectif de faire émerger
des standards pour l’intégration d’applications distribuées hétérogènes à
partir des technologies orientées objet. Les concepts clés mis en avant
sont la réutilisabilité, l’interopérabilité et la portabilité de composants
logiciels. CORBA est un bus d’objets répartis qui offre un support
d’exécution masquant les couches techniques d’un système réparti
(système d’exploitation, processeur et réseau). CORBA prend en charge
les communications entre les composants logiciels formant les
applications réparties hétérogènes (Figure 4-1). Le bus CORBA propose
un modèle orienté objet client/serveur pour la coopération entre les
applications réparties. Chaque application peut exporter certaines de ses
fonctionnalités (services) sous la forme d’objets CORBA : c’est la
composante d’abstraction de ce modèle.
Figure 4-1 Notion client/serveur avec le bus de CORBA, [Geib and Merle,
2000], (p. 7).
Mayyad JABER 62
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Les interactions entre les applications sont réalisées par
l’invocation à distance de méthodes associées aux objets. C’est la partie
coopération. La notion client/serveur intervient uniquement lors de
l’utilisation d’un objet : l’application implantant l’objet est le serveur,
l’application utilisant l’objet est le client. Selon les traitements
effectués, on notera qu’une application peut tout à fait être à la fois
cliente et serveur. Dans la figure précédente, on identifie les éléments
suivants : [Geib and Merle, 2000], [Koca, 2000]
L’application cliente est un programme qui invoque les méthodes
des objets à travers le bus CORBA.
La référence d’objet est une structure désignant l’objet CORBA et
contenant l’information nécessaire pour le localiser sur le bus.
L’interface de l’objet est le type abstrait de l’objet CORBA
définissant ses opérations et attributs. Cette interface est définie par
l’intermédiaire du langage OMG-IDL
La requête est le mécanisme d’invocation d’une opération ou d’un
accès à un attribut de l’objet.
Le bus CORBA achemine les requêtes de l’application cliente vers
l’objet en masquant tous les problèmes d’hétérogénéité (langages,
systèmes d’exploitation, matériels, réseaux).
L’objet CORBA est le composant logiciel cible. C’est une entité
virtuelle gérée par le bus CORBA.
L’activation est le processus d’association d’un objet implémentant
un traitement à un objet CORBA.
L’implantation de l’objet est l’entité codant l’objet CORBA à un
instant donné et gérant un état de l’objet temporaire.
Le code d’implantation regroupe les traitements associés à
l’implantation des opérations de l’objet CORBA.
L’application serveur est la structure d’accueil des objets
d’implantation et des exécutions des opérations.
Le standard CORBA offre une solution ouverte et évolutive
avec une architecture modulaire garantissant l’interopérabilité entre des
composants hétérogènes, tout en gardant un choix libre pour les
technologies d’implantation. Cette norme offre la possibilité
d’encapsuler l’existant : ainsi, on peut réutiliser totalement des
Mayyad JABER 63
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
applications complètes peut être réalisée en les encapsulant dans des
objets CORBA, objets utilisables pour bâtir de nouvelles applications.
Par contre, du fait de sa complexité et de son coût de mise en
œuvre (ad hoc pour chaque entreprise) assez élevé, CORBA n’a pas été
adopté par les géants de logiciels comme Microsoft et IBM. Il en résulte
un manque d’outils de support pour cette technologie.
4.3 Interopérabilité technique
Dans le Chapitre 3, nous avons abordé les problèmes issus de
l’interopérabilité organisationnelle au niveau du processus commun
distribué. Nous avons présenté une vision basée sur le standard RM-
ODP. Dans ce cadre, le processus commun peut être organisé comme un
assemblage de processus liés aux processus privés de partenaires. Les
processus publics basés sur RM-ODP sont donc à la fois isolés des
processus privés et interopérables. L’enjeu essentiel du processus
commun résultant est d’assurer l’échange de données entre les
partenaires de la chaîne logistique. Or, les données appartenant aux
différents partenaires sont hétérogènes et peu interopérables. C’est ce
problème que nous allons développer dans la section suivante.
4.3.1 Interopérabilité de données
Les partenaires ont besoin d’échanger des données syntaxiquement et
sémantiquement interopérables. Il faut donc disposer de formats et d’une
ontologie en commun pour pouvoir appréhender ces informations aux
plans syntaxiques et sémantiques. Selon le type de processus
(conception, production, gestion globale…), et l’acteur en charge de la
décision, différents types d’informations doivent être partagés. Pour
cela, un format d’échange général et une politique d’intégration des
contraintes de sécurité doivent être définis.
Une technique simple est réalisée par l’interconnexion de tous
les éléments d’information à partager dans une structure lâchement
couplée en se basant sur des objets métier communs. Ce couplage lâche
(interconnexion via le partage d’information) donne une grande
souplesse du système d’information global.
Mayyad JABER 64
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.3.2 Objets métiers et RM-ODP
Avec RM-ODP, le cadre de spécification du système est basé sur une
approche de modélisation d’objets. La modélisation basée sur les objets
est une pratique de conception formelle qui offre abstraction et
encapsulation de données. L’abstraction permet de mettre en lumière les
données liées à un processus précis, tout en cachant les informations et
les données qui n’ont pas d’importance. L’encapsulation est la propriété
par laquelle l’information contenue dans un objet n’est accessible que
par des interactions via les interfaces proposées par l’objet. La mise en
œuvre interne d’un objet est donc cachée aux autres objets. Cela est
fondamental pour faire face à l’hétérogénéité entre les systèmes supports
utilisés dans la chaîne logistique.
Les avantages de la technologie objet sont dus à la création des
composants réutilisables et compatibles par rapport au domaine
concerné. Un référentiel d’objets métier peut être mis en place afin de
garantir l’interopérabilité de données entre les partenaires. Dans notre
contribution, nous donnerons les détails techniques de ce référentiel qui
offre les objets nécessaires pour encapsuler les données hétérogènes à
échanger au sein de la chaîne logistique.
4.3.3 Interopérabilité des systèmes d’information
Les partenaires de la chaîne logistique doivent adopter une politique
commune pour une meilleure intégration de leurs systèmes
patrimoniaux. Cette intégration devrait supporter la collaboration entre
les partenaires de la chaîne logistique à différents niveaux tels que le
partage des ressources, des processus métiers, des règles métiers, des
informations, etc. Afin de supporter efficacement cette collaboration
organisationnelle, une architecture distribuée doit être en mesure de
mettre en œuvre et exécuter des processus métier distribués (Distributed
Business Processes), permettant à la fois l’exécution locale et à distance
de services tout en garantissant le même niveau d’efficacité.
Cependant, chaque partenaire d’une chaîne logistique possède
son système d’information patrimonial utilisé pour supporter les
processus locaux. Puisque les systèmes patrimoniaux sont souvent
Mayyad JABER 65
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
hétérogènes [Cha et al., 2004], une infrastructure interopérable doit être
établie pour la mise en œuvre des processus métiers distribués. Cette
interopérabilité implique que les partenaires se mettent d’accord sur les
mêmes techniques d’exposition et de gestion pour leurs ressources. A la
différence d’une étroite intégration de deux ou plusieurs systèmes
d’information (où l’accent est mis sur le développement d’un système
middleware conduisant à un système étroitement couplé), les chaînes
logistiques imposent un couplage lâche du fait de la nature temporelle et
évolutive de la collaboration. Pour atteindre cet objectif, on peut se
baser sur les architectures orientées services (SOA). Nous détaillerons
dans les sections suivantes comment cette approche peut apporter
l’interopérabilité entre les systèmes d’informations des partenaires au
sein de la chaîne logistique.
4.4 Architecture orientée service
L’évolution permanente du marché marquée par l’arrivée de derniers
canaux de ventes – Internet ou utilisateurs nomades – et l’évolution des
exigences du client a montré les difficultés rencontrées dans
l’intégration de nouvelles technologies dans les systèmes patrimoniaux
des entreprises. Les entreprises font face à des nombreuses pressions
introduites par la personnalisation et l’amélioration qualitative des
produits et des services et par la réduction du délai de mise sur le
marché (time-to-market). A cet effet, les entreprises font évoluer en
continu, leurs processus métiers. En conséquence, ces évolutions
engendrent des coûts élevés de maintenance ou d’évolution des
applications (basées sur des développements spécifiques ou sur des
progiciels). Une grande partie des dépenses concernant les outils
informatiques est consommée dans la maintenance et le support de ces
systèmes, laissant peu de marge pour l’innovation et l’investissement sur
les nouvelles technologies.
En outre, l’explosion de l’utilisation des technologies de
l’Internet a imposé des standards ouverts pour répondre aux exigences
d’interopérabilité. Ces standards offrent des environnements de
développement et d’exécution interopérables pour les processus
interentreprises. La flexibilité de processus interentreprises est
indispensable afin de supporter la production temporelle « en
Mayyad JABER 66
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
partenariat » de produits ou services composites. Dans ce contexte,
l’organisation de la chaîne logistique doit supporter la flexibilité requise
par les entreprises membres. Basée sur l’échange de donnée, cette
organisation doit faciliter la circulation de donnée à la fois
interentreprises et intra-entreprise. Pour ce faire, cette organisation doit
comporter des technologies permettant de réduire les coûts du support
informatique tout en gardant l’efficacité et la flexibilité de système
résultant. Les Architectures Orientées services (SOA) peuvent répondre
efficacement à cet objectif [BEA, 2006].
En effet, le principe de SOA est fondé sur la réorganisation du
système d’information à base de services lâchement couplés. Dans une
architecture orientée services, un service est une fonction métier
autonome et sans état. Un service peut être invoqué par une ou plusieurs
requêtes et retourne une ou plusieurs réponses à travers une interface
standard. Les services implémentent des règles de business, des calculs
et se chargent de l’exécution de transactions, etc. Ces services sont
indépendants : ils ne dépendent pas de l’état des autres fonctions ou
processus. La technologie utilisée pour implémenter le service, tel que le
langage de programmation, ne fait pas partie de la définition du service.
Un service ne doit pas dépendre d’une condition provenant d’un autre
service. Il doit recevoir toute l’information dont il a besoin pour fournir
une réponse à la requête qui a permis son activation. L ’absence de
dépendance entre services et consommateurs de ces services permet de
les impliquer dans de nombreux flux réalisant la logique applicative des
processus métiers.
Une architecture orientée services peut intégrer le patrimoine
applicatif existant de l’entreprise. L’organisation de ce patrimoine peut
être vu comme une juxtaposition de « silos », chacun d’eux associé à un
progiciel (tels que des ERP, des TMS…) ou à des applications
spécifiques. Chaque système est en général limité à un nombre restreint
de processus (disjoints) de l’entreprise, tels que la gestion de la relation
client (CRM), la gestion de la chaîne logistique, la recherche et le
développement, la facturation et la gestion financière, la gestion des
ressources humaines, etc. Un accès aux systèmes patrimoniaux doit être
mis en place afin de permettre aux nouveaux services métiers d’accéder
aux données de l’entreprise en respectant les conditions suivantes
[Krafzig et al., 2004]:
Mayyad JABER 67
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le cœur du métier doit être stable et fiable : en effet les services
d’interface sont quasiment invariants vis-à-vis l’évolution de
processus métier physiques ; ils exposent les fonctionnalités des
applications existantes.
L’interface entre les services et les données du coeur de métier doit
être standardisée.
Les interfaces de services doivent être dissociées de
l’implémentation.
4.4.1 Les avantages des architectures SOA
Les architectures orientées services offrent une flexibilité et une
meilleure résilience, (notamment en termes de disponibilité) au système
d’information. Leur rôle est de mutualiser la gestion des processus en
permettant l’accès aux processus des applications internes, et en
assurant l’interopérabilité entre les systèmes de façon indépendante des
technologies sous-jacentes, grâce aux standards applicatifs des
architectures orientées services [Fournier-Morel et al., 2006]. Ces
architectures apportent trois avantages majeurs :
Réactivité : la création des processus métiers interentreprises obtenu
par la composition de services distribués permet d’accélérer la mise
en œuvre d’une solution pour répondre à un nouveau besoin métier
engendré par l’évolution des conditions de marché.
Evolutivité : la possibilité de mettre en place des processus métiers
évolutifs qui sont recomposables selon les modifications des besoins
de l’entreprise.
Flexibilité : mise en œuvre de nouveaux processus métiers à partir
de services. Ces processus métier peuvent devenir à leur tour de
nouveaux services utilisables pour construire de futurs processus
métiers plus complexes.
En proposant une véritable transformation du système
d’information, les architectures orientées services permettent à
l’entreprise de diversifier ses canaux de vente et de distribution mais
aussi ses sources d’approvisionnement indépendamment de la
technologie de systèmes d’information patrimoniaux.
Mayyad JABER 68
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.4.2 Pourquoi la SOA pour la chaîne logistique
La SOA offre une capacité de réaction flexible durant le cycle de vie de
l’organisation associé à la chaîne logistique : tous les processus
accessibles par les clients et les partenaires sont intégrés dans un
système collaboratif basé sur les règles métier de la chaîne logistique.
Ceci permet aux entreprises membres de développer leur stratégie
marketing en temps réel en se basant sur les communications et les
transactions réalisées en partenariat avec les partenaires. Cette fonction
est assurée au niveau du socle de l’architecture, en synthétisant et en
analysant les flux de données, pour créer de nouvelles pratiques métier.
En plus, la SOA permet d’utiliser des services génériques. En se basant
sur ces services, les entreprises peuvent s’adapter en temps réel afin de
répondre aux besoins du marché. L’utilisation de standards ouverts
permet une adoption rapide et moins coûteuse des meilleurs pratiques
métiers au sein de l’organisation et de son écosystème.
En outre, l’application des architectures orientées service dans
le domaine de la chaîne logistique facilite l’expansion du champ
d’activité. Ces nouvelles possibilités accompagnent de nouveaux
modèles métiers vers de nouveaux marchés et de nouveaux canaux de
distribution. La participation collaborative des clients est intégrée dans
le développement des offres, du marketing et de la production. Les
architectures orientées services facilitent le prototypage et
l’industrialisation des nouveaux processus grâce à l’ouverture des
systèmes patrimoniaux par le biais de services.
4.4.3 Composition des architectures SOA
Les processus métiers sont modélisés sous forme de graphes de
composants. Ils coordonnent les appels aux services métiers et assurent
la persistance des données nécessaires pour leurs appels, au moyen de
technologies standard. La SOA propose aux applications (propres à
l’entreprise) des interfaces pour accéder aux services et aux données
métiers. Ces interfaces doivent être sécurisées et consistantes. Pour cela,
la mise en œuvre d’un système support basé sur la SOA doit prendre en
compte les conditions suivantes [BEA, 2006]:
Mayyad JABER 69
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Un service doit fonctionner de manière autonome "stand alone" pour
être isolé des autres traitements du système d’information.
Un processus métier comporte une entrée, une sortie mais aussi une
sortie d’exception pour traiter les états issus de pannes potentielles.
Le système résultant doit posséder des dispositifs dédiés pour
prendre en charge la mémoire de l’état conversationnel entre deux
appels de services.
Les applications collaboratives résultantes sont beaucoup plus
flexibles que les services du coeur de métier. En effet, une architecture
orientée services permet de fluidifier les communications et d’éviter les
transformations successives d’informations.
Plusieurs services supports sont implémentés dans une
architecture orientée services pour faciliter l’utilisation des services,
leur déploiement et leur administration :
Des services de sécurité réalisent des fonctions d’identification,
d’authentification et d’habilitation (gestion d’identités et des
autorisations).
Des services d’accès sous forme de portails destinés aux canaux
d’échange hétérogènes.
Des services de gestion et de supervision chargés de la gestion de
transaction, de la mesure de la qualité de service, de la gestion de la
disponibilité, etc.
La standardisation des infrastructures permet de réduire les
coûts en évitant les développements redondants inutiles. Une
architecture orientée services s’appuie sur des infrastructures et des
utilitaires de production et de pilotage. Les services qui assurent
l’interopérabilité sont composés à partir des services supports ouverts
sur l’écosystème de l’entreprise pour faciliter les échanges avec les
partenaires. L’objectif est de faciliter les échanges entre différents
systèmes d’information au sein de la chaîne logistique.
4.4.4 Implémentation de SOA
La mise en œuvre d’une architecture SOA nécessite des services
d’intégration permettant d’organiser les échanges entre applications, et
Mayyad JABER 70
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
plus particulièrement en termes de conversion de données. Les langages
de description de données comme XML sont utilisés pour représenter les
données à échanger. Des efforts importants sont actuellement menés par
les grands acteurs de l’industrie informatique pour standardiser des
schémas XML métiers. Les processus métiers communs sont des
applications collaboratives fonctionnant à travers les systèmes existants.
Ils utilisent les services métiers et peuvent être appelés par d ’autres
processus internes ou externes à l’entreprise. L’architecture orientée
services du système d’information utilise les processus métiers comme
des briques de base. Le système doit être flexible pour permettre l ’ajout
de nouveaux processus métiers.
L’industrie informatique propose de nouvelles solutions
technologiques pour simplifier et rendre efficace la mise en œuvre des
systèmes d’information à base de service. Les premiers services Web
(ou Web Services (WS)) sont apparus au début des années 2000. Les
services Web peuvent être utilisés pour résoudre les problèmes en
termes d’interopérabilité entre les systèmes patrimoniaux des
entreprises. Les solutions basées sur les services web ont adopté les
solutions d’intégration basées sur l’approche SOA. L’adoption des
services Web s’est généralisée et est devenue un standard reconnu dans
le contexte de e-business. De nombreux éditeurs ont déjà adopté les
principes des architectures orientées services (SOA) avec les standards
de services Web. Ces nouvelles technologies ont facilité l’usage de
l’Internet comme une infrastructure de collaboration intra et
interentreprises. Dans la section suivante, nous allons présenter les
Services Web comme des composants de base pour la SOA.
4.5 Les Services Web
Pendant des années, les concepteurs et les développeurs de composants
des systèmes d’information ont essayé de répondre à la cette question :
comment modifier, incrémenter, et relier dynamiquement des
applications hétérogènes pour répondre aux exigences de business. Le
paradigme de web services (WS) a émergé comme un mécanisme
puissant pour intégrer les systèmes d’information distribués. Combinant
les meilleurs aspects du développement dans le domaine de construction
des systèmes d’information à base de composants avec les facilités
Mayyad JABER 71
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
offertes par le web, les services Web sont utilisés pour implémenter le
concept de SOA [Albani et al., 2003].
Un service en général (et plus particulièrement un service web)
représente une fonctionnalité qui peut être facilement réutilisée sans
avoir à connaître ni les détails ni la façon dont le service est construit.
Puisque les protocoles du web sont complètement indépendants des
fournisseurs, des plateformes et des langages de mise en œuvre, les
applications résultant de la mise en œuvre des technologies de services
web sont à la fois intégrables dans l’environnement de business, et
suffisamment flexibles pour faire face aux modifications potentielles
dans un monde très évolutif tel que celui du e-commerce.
Les applications construites en se basant sur les services Web
offrent les mêmes fonctionnalités que celles qui sont mises en œuvre
selon une architecture monolithique mais en plus on peut constater les
bénéfices suivants : [Papazoglou, 2003], [Cardoso et al., 2004]
Une extension plus facile pour les règles de business afin de les
appliquer aux nouvelles fonctionnalités "coopératives ".
La flexibilité de modifications sans avoir besoin de reconstruire la
structure de base.
La réduction du coût d’intégration en utilisant des protocoles de
référence.
Un service web est un service d’application (c’est-à-dire une
fonction accessible depuis le réseau) qui peut être consulté en utilisant
des protocoles standards du web. Les services web indiquent entre autres
l’ensemble des standards qui assurent l’interopérabilité entre les
différents services. Le concept de service web inclut les caractéristiques
suivantes : [Cardoso et al., 2004]
L’accessibilité depuis l’Internet : les services web communiquent
via des protocoles liés au web, indépendants d’une plateforme ce qui
facilite l’intégration entre des environnements hétérogènes.
Les standards des services web définissent une interface et un
protocole de communication permettant l’enregistrement de ces
services sur un serveur, pour faciliter l’invocation de leurs
fonctionnalités par une application cliente.
Mayyad JABER 72
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le langage de définition de services web WSDL (Web Services
Definition Language) met en place une couche d’abstraction entre
l’implémentation et l’interface, fournissant une application
configurable. Ceci garantit la flexibilité de l’application résultante.
L’avantage premier de l’approche basée sur les services Web
est l’adoption à une large échelle de ses technologies. Cela permet aux
entreprises d’effectuer une transition incrémentale vers une architecture
orientée service avec des risques minimaux et donc de limiter les coûts.
4.5.1 Les standards utilisés par les services Web
Les services web sont bâtis en se basant sur des standards ouverts et
largement adoptés comme http et eXtensible Markup Language (XML).
Ces standards sont maintenus par des organisations indépendantes sans
but lucratif. Il en résulte des standards ouverts et gratuits selon lesquels
des applications et des outils compatibles avec les services web sont
construits. Quelques groupes majeurs de standardisation de services web
sont cités : [Curbera et al., 2002]
W3C (World Wide Web Consortium) : Consortium majeur gérant la
plupart des standards largement adoptés dans le domaine de service
web, incluant l’implémentation de patrons de code et de standards
comme HTML.
OASIS (Organization for the Advancement of Structured
Information Standards) : Source originale de la spécification
concernant l’évolution de XML. Cette organisation gère
actuellement les spécifications de XML et UDDI (Universal
Description, Discovery and Integration) [OASIS, 2005].
WS-I (Web Services Interoperability Organization) : Groupe dont
l’objectif est d’assurer l’interopérabilité entre les implémentations
diverses des standards de services web.
Dans les paragraphes suivants, nous allons introduire les
standards qui jouent un rôle vital dans l’environnement des services
Web.
Mayyad JABER 73
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.5.1.1 XML : eXtensible Markup Language
XML concerne les spécifications liées à la customisation des types de
documents, en utilisant des formats lisibles par l’Homme. Les
spécifications de XML renforcent les règles de construction des
documents. XML permet aux développeurs de créer leurs propres
balises, permettant la définition, la transmission, la validation, et
l’interprétation de données entre les applications et les organisations.
Les services web communiquent en utilisant XML (interfaces
et messages de XML interprétables facilement par les applications) pour
décrire leurs interfaces et encoder leurs messages et en s’appuyant sur
les protocoles standards de web comme les protocoles SOAP (Simple
Object Access Protocol), UDDI (Universal Description, Discovery and
Integration), et WSDL (Web Services Description Language) pour
réaliser l’interaction. Ces standards utilisent également XML [Girard
and Crusson, 2001].
4.5.1.2 SOAP : Simple Object Access Protocol
SOAP est un standard qui représente une « enveloppe » légère contenant
la charge utile "payload" des messages échangés entre les producteurs et
consommateurs de services. C’est un standard basé sur XML qui décrit
le contenu du message échangé ainsi que la façon de traiter ce contenu.
Ce protocole permet en outre une association avec les protocoles de
transport. SOAP offre aussi un groupe de règles d’encodage pour
exprimer les instances des types de données définies par les applications
et une convention pour représenter les invocations à distance et les
réponses des applications. Voici les éléments principaux de ce standard :
[Curbera et al., 2002], [SOAP, 2007]
L’enveloppe de SOAP (SOAP Envelop) décrit le contenu du message
et la façon de traiter ce contenu. Il contient en outre des détails
supplémentaires ainsi que les informations liées à la sécurité ou à la
destination finale du message.
Le cadre d’association avec le transport (SOAP Transport Binding
Framework) est un cadre abstrait pour l’échange des « enveloppes »
en utilisant un protocole de communication sous-jacent comme
HTTP.
Mayyad JABER 74
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le cadre de sérialisation (SOAP Serialization Framework) est
constitué par un groupe de règles pour exprimer les instances des
types de données définies par les applications (ainsi que les chiffres
et le texte).
La représentation des appels des procédures à distance (SOAP
Remote Procedure Calling Representation) est une convention pour
représenter les invocations et les réponses des applications à
distance [OMG, 2005].
4.5.1.3 WSDL : Web Services Description Language
WSDL est un langage au format de type XML utilisé pour la description
des services offerts sur un réseau. Ce langage décrit les interfaces des
messages contenants des information orientées documents ou orientées
procédures. Les opérations et les messages sont décrits de manière
abstraite. Ces descriptions sont ensuite couplées au système de transport
(spécifiant le format des messages et les protocoles réseau) pour définir
les points de connexion aux services afin de définir une extrémité. Les
messages sont associés au protocole SOAP et au protocole de transport
HTTP. La nature abstraite de WSDL (défini comme un outil de
description pour les services) fournit la flexibilité nécessaire pour
décrire des applications complexes des services web. Un document
WSDL utilise les éléments suivants pour la définition des services :
[Curbera et al., 2002]
Types : conteneur pour la définition de type de données comme XSD
(XML Schema Definition).
Message : définition typée abstraite des données communiquées.
Opération : description abstraite pour une action supportée par le
service
Type de port : groupe d’opérations abstraites supportées par une ou
plusieurs extrémités.
Association : protocole concret ainsi qu’une spécification pour un
format de donnée dédié à un type de port précis.
Port : extrémité définie comme une combinaison d’une association
avec une adresse réseau.
Service : collection des extrémités reliées.
Mayyad JABER 75
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.5.1.4 UDDI : Universal Description, Discovery and Integration
UDDI représente un groupe de protocoles et un répertoire public pour
l’enregistrement et la recherche en temps réel des services web et autres
processus métier. UDDI supporte un registre pour les services Web
fournissant une liste des services disponibles sur un réseau. Un serveur
UDDI permet aux organisations de : [UDDI, 2007]
Héberger plusieurs versions pour le même service
Créer des alias pour leurs services
Limiter l’accès à certains services
Bien que le UDDI soit un standard ratifié, il continue d’évoluer
et reste susceptible de changements fréquents, afin de s’adapter aux
évolutions des exigences du monde du Business.
Contrairement aux applications traditionnelles bâties sur une
interconnexion étroite de leurs composants, les services web permettent
de construire des processus avec un couplage lâche. Le couplage lâche
signifie que chaque service existe et peut fonctionner indépendamment
des autres services constituant l’application. Cela permet aux
composants des applications d’être modifiés sans aucun impact sur les
éléments non concernés.
Par ailleurs, l’exécution d’une application supportant un
processus commun intégrant différents services peut s’étaler sur une
longue durée et contenir de longues périodes de veille. Ces périodes de
veille sont souvent dues aux nécessaires interactions avec l’utilisateur.
Dans un environnement à couplage lâche comme le web, il est inévitable
que ces applications (qui sont construites à partir de composants
distribués), exigeront des moyens pour traiter les échecs éventuels soit
parce que les machines sont susceptibles de pannes soit parce que les
services peuvent être déplacés, modifiés, ou supprimés. Une technique
communément utilisée pour améliorer la tolérance aux pannes est
l’utilisation du concept de transaction. Les transactions garantissent que
seulement les changements cohérents et stables auront lieu en dépit de
l’accès concourant aux informations et des risques d’échec. Le
paragraphe suivant apporte un éclairage sur la notion de transaction dans
les applications orientées services et composées à partir de services
Web.
Mayyad JABER 76
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
4.5.2 Gestion de transactions atomiques et validation en deux
phases
En se basant sur les notions du processus métier présentées dans le
Chapitre 3, le processus interentreprises peut être définit par
l’assemblage des activités des partenaires pour constituer un Workflow
global. Ces activités qui représentent les sous-processus du processus
commun sont supportées techniquement par le biais de services Web.
Les spécifications de services Web (WSDL, SOAP…), définissent des
protocoles pour garantir l’interopérabilité des Services Web. Les
services Web permettent de constituer des applications à grande échelle
compte tenu des possibilités d’interconnexion et du grand nombre de
participants pouvant être impliqués dans une chaîne de services. Les
applications résultantes possèdent une architecture assez complexe
imposant ainsi un système de coordination entre les composants.
Le protocole WS-Coordination est une spécification qui
propose un cadre extensible pour définir les types de coordination entre
les services web. Cette spécification fournit une définition du type de
coordination pour une opération atomique. La définition peut être
utilisée pour coordonner les activités ayant la propriété "tout ou rien"
[Papazoglou, 2003], [Ren et al., 2004].
4.5.2.1 Les transactions atomiques
Les transactions atomiques possèdent une propriété de "tout ou rien".
Elles exigent généralement un niveau élevé de fiabilité dans les moyens
de communication et sont de courte durée. La spécification des
transactions atomiques définit les protocoles existants à utiliser pour
permettre aux systèmes de traitement des transactions d’encapsuler leurs
propres protocoles. Elle permet aux différents participants d ’inter-opérer
malgré des matériels et logiciels hétérogènes. Les mesures prises avant
de valider une transaction sont provisoires (c’est-à-dire, non persistantes
et non visibles pour les autres activités). Quand une application se
termine, elle demande au coordinateur de déterminer l’issue de la
transaction. Le coordinateur détermine s’il y a eu des échecs de
traitement en demandant aux participants de voter. Si le vote de tous les
participants impliqués lors de l’exécution est "avec succès", le
coordonnateur confirme toutes les actions prises. Si un participant au
Mayyad JABER 77
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
vote répond avec "avorté" ou si un participant ne répond pas, le
coordonnateur annule (abort) toutes les actions prises. La validation
(commitment) rend les résultats provisoires des actions visibles aux
autres opérations. Lors d’une annulation, tout redevient comme si les
actions exécutées "provisoirement" ne s’étaient jamais produites.
Les transactions atomiques sont extrêmement précieuses pour
les applications monolithiques. Elles fournissent des moyens pour
résister face aux échecs (non prévus) en utilisant des mesures de
récupération. Les transactions atomiques définissent aussi les protocoles
qui contrôlent les résultats des opérations atomiques. Du point de vue
technique, les systèmes de gestion de transactions encapsulent les
mécanismes propres des tâches sous-jacentes afin de garantir
l’interopérabilité entre les différentes implémentations des processus
distribués.
4.5.2.2 Le protocole 2PC
Les transactions atomiques sont basées sur une règle dite
d’aboutissement intégral qui impose aux participants de la transaction
globale de s’engager pour aboutir à un résultat cohérent. Pour apporter
cette garantie, l’exécution de transactions atomiques est réalisée grâce
au protocole de validation à deux phases (2PC : two Phases
Commitment) Pour chaque participant inscrit, le coordonnateur
déclenche l’exécution de sa tâche en se basant sur le protocole de deux
phases (2PC : two Phases Commitment). Le protocole 2PC coordonne
les tâches des participants inscrits pour atteindre une validation intégrale
(commitment) ou une annulation de la transaction. Ce protocole veille à
ce que tous les participants ainsi que l’initiateur de transaction globale
soient informés du résultat final.
Dans le domaine de la chaîne logistique, à cause du niveau
élevé d’agilité requis, les protocoles de type 2PC ne sont pas en mesure
de satisfaire les exigences nécessaires pour la gestion du processus
commun. Prenons l’exemple d’un ordre d’achat où plusieurs partenaires
de la chaîne logistique doivent collaborer pour satisfaire cet ordre
d’achat. Dans le cas où le transporteur annonce qu’il n’est pas capable
de répondre à la commande, la décision doit être laissé au client pour
confirmer la transaction ou non (il se peut qu’il trouve d’autres moyens
pour assurer le transport). En conséquence, une adaptation particulière
Mayyad JABER 78
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
doit être réalisée sur les transactions classiques et les protocoles 2PC
afin de satisfaire les exigences liées à la gestion du processus commun
de la chaîne logistique.
4.5.3 Modèles de transaction traditionnels
Pour permettre d’obtenir un niveau d’agilité et de reconfiguration
suffisant dans le contexte du B2B, ces approches doivent être amendées.
En effet, si les transactions ACID ont été très précieux dans la
construction d'applications d'entreprise, elles sont adaptées aux
exécutions des activités à courte durée avec des applications fortement
couplées. Lorsqu'elles sont utilisées dans un environnement faiblement
couplé, elles s'avèrent trop rigides et limitent le contrôle des
applications dans le domaine de B2B. En effet, Dans un système de
transaction traditionnel, l’ensemble de tâche effectuées dans une
transaction doit soit être acceptées (commis) ou annulées et ce avec une
intégration de la gestion de ressources au cœur de l’environnement
applicatif. Pour s’adapter au couplage lâche induit par l’approche servie,
plusieurs modèles comme BTP (Business Transaction Protocol), WS-
Coordination, WS-Transactions etc. ont été développés pour résoudre ce
problème et en même temps pour maintenir les aspects du modèle de
transaction atomique qui sont utiles pour renforcer la cohérence des
processus distribués et lâchement couplé.
4.5.3.1 Busines Transaction Protocole
Le processus commun de la chaîne logistique est composé à partir de
sous-processus publics supportés par les systèmes patrimoniaux des
partenaires. Dans une approche orientée service, les processus
interentreprises sont des unités de travail distribuées et lâchement
couplées qui sont exécutées dans un milieu non stable. Pour répondre à
ce problème, le standard BTP offre des facilités pour contrôler
l’exécution des services Web distribués dans un environnement peu
fiable [Papazoglou, 2003]. Le principe de BTP est basé sur l‘utilisation
des "atomes" et des "cohésions". Une cohésion est d'abord créée pour
gérer l'ensemble des interactions de business. Les applications
concernées créent des atomes qui s'inscrivent à la cohésion avant
d'invoquer les autres applications engagées le cadre de la cohésion.
Mayyad JABER 79
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
L’exécution de ces applications est ensuite contrôlée par la "cohésion"
en lumière des résultats des atomes. La cohésion représente la logique
d’assemblage ainsi que le flux de contrôle avec un ou plusieurs atomes.
Bien que les services Web fonctionnent dans le cadre des atomes, c’est
la cohésion qui détermine en fin de compte quels atomes de confirmer
ou d’annuler. La cohésion peut préparer et/ou annuler des atomes
pendant la durée de l'opération. La principale différence entre un atome
et une cohésion est que, alors que tous les participants inscrits à un
atome doivent soit confirmer soit annuler, les participants inscrits à la
cohésion (les atomes) peuvent avoir des résultats différents. Cependant,
une fois que la cohésion est parvenu à confirmer (l’ensemble ou un
sous-ensemble des atomes dans son contexte), il se transforme en un
atome et garantit la règle de "tout-ou-rien". Si ce protocole permet
d’avoir un couplage plus lâche que X/Open DTP, en revanche il ne
permet pas de s’adapter au contexte.
4.5.3.2 Coordination et gestion de transaction pour les services Web
WS-Coordination décrit une spécification cadre extensible qui fournit de
protocoles de coordination pour l’exécution des applications distribuées
en prenant en compte la contextualisation. Ces protocoles de
coordination offre un support pour les services distribués qui ont besoin
de parvenir à un résultat cohérent. Le WS-Coordination est favorable à
la notion de plug-in pour les modèles de coordination. Le modèle de
coordination représente un ensemble de protocoles de coordination. Un
protocole de coordination est l'ensemble des messages bien définis qui
sont échangés entre les participants d’une transaction [Papazoglou,
2003].
WS-Coordination offre un moyen de gérer les activités liées à
un processus métier distribué. Un processus métier peut impliquer un
certain nombre de services Web afin de réaliser un objectif métier
commun. Chaque service doit être capable de coordonner ses activités
avec celles des autres services afin qui le processus réussit. WS-
Coordination dirige les tâches dans un processus composé à partir de
services Web interopérabls pour parvenir à un accord sur le résultat
global du processus. Cela est réalisé par fournir des mécanismes
standard permettant la création d’une activité par un service
d’activation. Cette activité s’engage dans un protocole de transaction qui
Mayyad JABER 80
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
contrôle l’exécution des services Web comme WS-Transaction et WS-
Business Activity.
Dans le domaine de B2B, les services Web sont liés à un grand
nombre de participants formant ainsi des grandes applications
distribuées. WS-Transaction définit comment les services Web peuvent
coordonner leurs activités afin d'assurer l'intégrité des opérations au
niveau de ressources et de bases de données avec les quelle ils sont
associés. WS-Transaction définit deux modèles de transactions pour les
services Web : les transactions atomiques et les transactions pour les
activités de business. Une transaction atomique est utilisée pour
coordonner les activités ayant une courte durée et exécuter dans des
environnements avec un niveau élevé de protection. La transaction
atomique conforme avec les propriétés ACID et garantit ainsi que tous
les participants confirment ou annulent la transaction "tout ou rien"
[Papazoglou, 2003].
Les transactions d’activité métier (WS-Business Activity)
offrent un support pour la gestion de transactions distribuées sans
nécessiter de bloquer toutes les ressources nécessaires [Papazoglou,
2003]. En général, une activité est conçue comme une séquence de
tâches. Chaque tâche répond aux contraintes d'une transaction atomique
avec la possibilité d’exécuter une activité de compensation. Plutôt que
demander à chaque participant de verrouiller des ressources et de tenir le
verrouillage jusqu'à ce que tous les participants confirment ou annulent
leurs tâches, la compensation assume que toutes les mises à jour au
niveau de ressources va réussir et engage les changements
immédiatement. En même temps une opération de compensation est
préparée comme un moyen de défaire les changements et donc de
compenser la défaillance de tout composant de la transaction globale.
Toutefois on note que ces solutions sont organisées au niveau techno et
n’apportent pas de solution pour le couplage au niveau métier.
4.6 Conclusion
La rapidité de l’évolution du marché conduit les entreprises à
développer des organisations souples et agiles. Pour s’adapter à ces
contraintes organisationnelles, les entreprises se concentrent sur leur
cœur de métier et sont de plus en plus impliquées dans des
Mayyad JABER 81
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
collaborations au-delà de leur frontière. Cela implique l’échange
d’informations entre partenaires et par conséquent de faire face aux
défis de l’interopérabilité entre les systèmes d’information
patrimoniaux.
Pour cela, les partenaires de la chaîne logistique doivent
adopter une politique commune visant une meilleure intégration des
systèmes patrimoniaux. Cette intégration devrait soutenir la
collaboration entre les partenaires de la chaîne logistique aux différents
niveaux tels que le partage des ressources, les processus métiers, les
règles métiers, les systèmes d’information, etc. Afin de supporter
efficacement cette collaboration organisationnelle, une architecture
distribuée doit être en mesure de mettre en œuvre et exécuter des
processus métier distribués (Distributed Business Processes), permettant
à la fois l’exécution locale et à distance de services tout en garantissant
le même niveau d’efficacité.
Dans le chapitre suivant, nous allons présenter une feuille de
route pour une architecture cadre pour un système d’information
distribué supportant le processus de la chaîne logistique. Il s’agit d’une
architecture basée sur les concepts de SOA et de système de gestion de
Workflow. L’enjeu essentiel est permettre la mise en place d’un
processus commun à base de services sous forme d’un Workflow global
distribué.
Mayyad JABER 82
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 5 Principe de solution et
feuille de route
5.1 Introduction
Les technologies de l’information et de la communication représentent
un enjeu majeur pour l’efficacité des chaînes logistiques : pouvoir
partager instantanément les informations recueillies auprès des
partenaires à tous les nivaux de la chaîne logistique conduit à une
réduction significative du temps de réponse, des coûts induits et du
niveau moyen des stocks. Le résultat est une amélioration significative
sur la performance globale de la chaîne logistique (section 2.2.1). Pour
atteindre cet objectif, nous présenterons notre vision sur l’intégration de
la chaîne logistique. Cette intégration facilite l’échange de l’information
d’une manière souple et efficace.
Au niveau organisationnel, nous allons décrire la composition
du processus commun en se basant sur les processus métiers distribués
des partenaires. A cette fin, nous allons développer une architecture
cadre orientée services pour permettre à des processus distribués de
communiquer via le Web. Dans ce cas, les difficultés principales
consistent en l’organisation de l’exécution du processus commun
distribué, incluant à la fois des processus publics et privés, ainsi que des
dispositifs de récupération en cas d’interruption des processus communs.
Dans ce chapitre, nous présenterons une feuille de route pour
l’architecture cadre. Il s’agit de la démarche que les partenaires dans un
contexte de B2B doivent appliquer afin d’interconnecter leurs systèmes
d’information. Les composants de base de notre architecture cadre sont
les systèmes patrimoniaux de partenaires. En effet, les systèmes
patrimoniaux forment un support pour les processus privés de chaque
entreprise. L’objectif de l’architecture cadre est de faire communiquer
Mayyad JABER 83
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
ces systèmes en assemblant les processus privés, encapsulés par des
services Web, formant ainsi un processus commun interentreprises.
Dans le contexte de la chaîne logistique, les processus privés
peuvent être organisés de manière formelle ou ad hoc. L’intégration de
ces différents types de sous processus nécessite une adaptation
spécifique. Afin de garder la flexibilité requise, cela doit être réalisé
sans imposer la transformation d’un type à un autre.
Avant de présenter notre proposition pour l’organisation du
processus commun, nous voulons montrer les caractéristiques au niveau
métier concernant la structure du processus commun que nous visons. A
cet effet, nous allons présenter les différents modes d ’interaction entre
les entités de business dans le domaine de B2B.
5.2 Les différents modes d’interaction commerciales
Selon l’importance de la relation avec un partenaire commercial, une
entreprise peut chercher à établir une collaboration stratégique ou bien
se contenter d’affaires « à la volée » [Jaber et al., 2005]. La structure du
processus commun (inter-organisationnel) dépend du mode d’interaction
entre les entreprises. Nous distinguons trois modes différents : affaires à
la volée, collaboration stratégique et le mode hybride. Les paragraphes
suivants portent sur ces différents modes ainsi que sur leur influence sur
la structure du processus commun et sur notre proposition d’architecture
cadre.
5.2.1 Affaires à la volée : "On the fly Deals"
Dans ce cas, chaque échange commercial est traité séparément des
autres opérations. Afin de garantir l’interopérabilité lors de l’exécution
du processus interentreprises, il suffit de se mettre d’accord sur le
modèle de données utilisé comme une base pour l’échange de
documents. Dans notre cadre, un service Web qui encapsule le document
à échanger est mis en place. Ce service décrit les données à échanger
(par exemple un bon de commande, une facture…). Afin de faciliter la
communication entre les systèmes hétérogènes et garantir que le format
de données sera correct et valide, un format commun peut-être utilisé
offrant ainsi une garantie d’un échange d’information souple. Nous
Mayyad JABER 84
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
traitons les notions concernant l’interopérabilité au niveau des données
dans la section 6.3.
5.2.2 Collaboration stratégique
C’est le cas des chaînes logistiques ou des entreprises virtuelles.
L’objectif est d’harmoniser les activités des partenaires en vu
d’améliorer la performance globale. Pour ce type de collaboration, les
processus communs sont mis en œuvre et organisés selon une logique de
relation à long terme. Comme pour le cas précédent, l’activité principale
consiste à échanger des informations commerciales. En revanche, la
nature des informations et la manière de faire cet échange sont
différentes. Dans ce cas, on échange non seulement les documents liés
directement à la conduite des opérations commerciales (comme les
factures et les bons de commandes par exemple) mais aussi, d ’autres
données utiles comme le niveau de stock, les délais de livraison , etc. en
temps réel. En outre, les informations liées à une transaction
commerciale (informations qui sont envoyées d’un partenaire à un autre)
pourraient être diffusées à d’autres partenaires ne prenant pas part à
cette transaction. A titre d’exemple, un fournisseur de fournisseur peut
anticiper la modification de ses plans dans le cas où le fournisseur reçoit
une confirmation d’une commande volumineuse imprévue. Ces activités
complémentaires, productrices de valeur ajoutée, sont réalisées en
fonction de l’organisation de la chaîne logistique ou de l’entreprise
virtuelle et contrôlées par des contrats commerciaux lors de la création
de l’organisation.
5.2.3 Le mode hybride
Dans le monde réel, les entreprises engagées dans une chaîne logistique
veulent préserver la possibilité de faire des affaires avec d ’autres
partenaires extérieurs à cette chaîne logistique. Pour cela, les entreprises
impliquées dans une chaîne logistique se mettent d’accord sur la
politique de partage de l’information : quelles sont les informations à
partager, comment elles seront échangées, quand elles seront diffusées,
qui a le droit de les obtenir. Parallèlement, chaque membre du groupe
garde la possibilité de faire des affaires avec des entreprises extérieures
Mayyad JABER 85
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
à la chaîne logistique (off-shore), en exploitant la structure dédiée à
l’origine pour la chaîne logistique. Dans le cas d’une transaction
commerciale entre les partenaires de la chaîne logistique, les sous-
processus sont invoqués et exécutés dans le cadre d’un processus
commun comprenant des activités complémentaires pour améliorer la
collaboration (cf. section 5.2.2). En revanche, ces services sont exécutés
dans le cas d’une affaire "à la volée" comme des composants autonomes.
Le mode hybride comporte des activités allant des affaires à la
volée à la collaboration stratégique. Nous nous intéressons à construire
une architecture permettant aux entreprises de collaborer par exercer à la
fois les deux types d’activités. Il s’agit de leur offrir les moyens
nécessaires pour coupler leurs processus privés de manière lâche.
5.3 Intégration des activités dans une chaîne logistique
La logique d’intégration dans la chaîne logistique permet aux entreprises
de parvenir à une plus grande coordination et collaboration avec leurs
partenaires. Cette intégration permet de réduire la complexité des
opérations de la chaîne logistique telles que les achats, la fabrication, la
gestion des stocks, la distribution, le service après-vente, et la
commercialisation. Dans notre travail, nous nous intéressons à proposer
une solution d’intégration pour la chaîne logistique qui va plus loin que
l’échange commercial interentreprises. Il s’agit d’un support
informatique de collaboration qui permet aux entreprises de coordonner
leurs activités de manière à augmenter la valeur introduite par la
création de la chaîne logistique.
Dans le contexte de la chaîne logistique, le support
informatique des processus métiers inter-organisationnels va plus loin
que l’exécution des opérations frontales (front-end) liées aux échanges
commerciaux, il faut aussi coordonner les opérations dorsales (back-
end) supportées par les processus privés dans les entreprises membres de
la chaîne logistique. Le processus d’intégration de la chaîne logistique
peut être réalisé par une approche de e-business et non pas e-commerce.
La coordination des processus privés est réalisée indirectement
par le biais des processus publics constituant le processus commun. En
tenant compte de cette réalité, le support informatique doit garantir une
intégration souple et efficace pour assembler les processus publics
Mayyad JABER 86
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
distribués dans un processus commun viable et fiable. Cet assemblage
est réalisé par le biais de l’échange d’information interentreprises.
5.3.1 Echange d’information
Le processus d’intégration de la chaîne logistique suppose de disposer
des moyens nécessaires pour échanger les informations entre les
partenaires de la chaîne logistique. Ces informations incluent tous les
types de données qui pourraient impacter la performance et les actions
réalisées par d’autres partenaires. A titre d’exemple, on pourra échanger
des informations sur la demande, l’état des stocks, la capacité de
production, des plans de production, des informations liées au
marketing, des horaires d’expédition… afin d’améliorer la performance
globale. Ces informations devraient être atteignables en ligne et en
temps réel pour les entreprises partenaires.
Une contribution majeure de l’échange d’information est la
synchronisation de la planification. La disponibilité de l’information
permet la mise en œuvre et l’exécution conjointe des plans pour le
lancement des nouveaux produits, des prévisions de ventes et du
réapprovisionnement. La synchronisation de la planification est réalisée
grâce aux informations partagées (par le biais de l’échange). Les
entreprises membres dans la chaîne logistique se mettent d’accord
mutuellement à propos des actions spécifiques à exécuter sur ces
informations. Ainsi, les membres de la chaîne logistique peuvent
coordonner leurs plans afin que toutes les transactions commerciales
soient harmonisées pour satisfaire un même objectif : répondre à la
demande des clients finaux.
Néanmoins, il faut toujours superviser la manière dont ces
éléments d’information sont accessibles. Pour cela, le processus
commun doit être organisé d’une manière permettant de contrôler
l’échange d’information interentreprises. Les notions d’organisation du
processus commun sont expliquées dans les sections suivantes.
5.3.2 Coordination du processus commun
Le processus de coordination entre les entreprises membres de la chaîne
logistique sous-entend une coordination efficace et automatisée des
Mayyad JABER 87
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
sous-processus privés. Par exemple, les activités liées au processus
d’achat entre une entreprise assurant la fabrication et un fournisseur de
matières premières peuvent être automatisées entièrement. Ceci offre
des gains d’efficacité, de temps et de coût lors de l’exécution du
processus commun. Le processus commun, est défini comme un
ensemble de processus interconnectés indirectement pour les processus
privés (boîtes noires pour lesquelles seules les interfaces sont connues)
et directement pour les processus publics (boites blanches avec une
description de processus bien précise).
Afin de répondre aux exigences d’ouverture, nous utilisons des
standards des architectures orientées services pour fournir un cadre
évolutif et réactif destiné à l’appui de la coopération interentreprises. Ce
cadre doit être capable de fournir les capacités d’interconnexion
nécessaires entre les systèmes d’information hétérogènes des
partenaires. Les composants de base du processus commun (c’est-à-dire
les sous-processus privés, les messages et la description du processus
commun) sont définis comme des unités réutilisables. Ces unités sont
sauvegardées dans un registre afin de permettre leur réutilisation pour
définir le processus commun interentreprises.
Pour simplifier la représentation du processus commun, nous
introduisons son organisation en sous-flux. Le processus commun peut-
être décrit comme un réseau du processus en s’appuyant sur le modèle
de processus composé par un ensemble de sous processus (section
3.3.5).
Quand il s’agit de la représentation du processus commun de la
chaîne logistique, nous distinguons deux types de sous processus vis-à-
vis du demandeur de services :
Sous processus interne : Il est composé d’une ou de plusieurs
tâches. Il est supporté par un système d’information local.
Sous processus externe : Il est aussi composé d’une ou de plusieurs
tâches. En revanche ce processus est contrôlé par le système
d’information d’un autre partenaire.
Les deux types de processus peuvent être utilisés comme des
composants de base du processus commun. L’exemple suivant présente
un processus métier distribué. Il s’agit du processus de traitement d’une
commande passée par le portail Web d’un fournisseur. La Figure 5-1
représente le processus principal en se basant sur le concept du
Mayyad JABER 88
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
processus décomposé en sous-flux. Dans notre exemple, nous avons
quatre entreprises :
L’entreprise A : il s’agit du fabricant des produits finaux, il est en
relation directe avec les clients.
L’entreprise B : un fournisseur de composants pour l’entreprise A.
L’entreprise C : un fournisseur de matières premières pour
l’entreprise B.
L’entreprise de transport assurant la livraison
Le processus principal est lancé quand un client passe une
commande auprès de l’entreprise A. D’abord, le processus de CRM
(Client Relationship Management) (qui est une application interne de
l’entreprise A) est activé pour enregistrer les informations concernant le
client. La deuxième tâche concerne la gestion des ressources : si le
vendeur ne possède pas un stock suffisant pour satisfaire la commande,
le support du processus local (un gestionnaire de Workflow dans notre
exemple) procède à l’activation du processus d’approvisionnement de
ces produits depuis un partenaire de la chaîne d’entreprises (l’entreprise
B). Ceci conduit à démarrer le Workflow de ce partenaire. Le sous-
processus concernant le traitement des produits commandés peut être
exécuté soit par le système local ou bien délégué à un sous-processus
externe. Ceci est déterminé en temps réel par le moteur du Workflow
global en se basant sur le contexte d’exécution du processus en cours.
Au-delà, les sous-processus externes peuvent à leur tour invoquer des
sous-processus externes. A titre d’exemple, l’entreprise B peut faire
appel à l’entreprise C pour assurer l’approvisionnement de matière
première. Dans la Figure 5-1, Les processus principaux (nœuds foncés
dans la figure) constituant le processus commun peuvent être délégués
aux processus externes contrôlés par les systèmes patrimoniaux des
partenaires.
Mayyad JABER 89
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 5-1 Exemple de processus métier distribué.
Dans ce cas, plusieurs applications ou gestionnaires de
Workflow peuvent être lancés afin d’exécuter le processus global.
Néanmoins, l’exécution du processus commun reste toujours sous le
contrôle du système d’information global.
L’organisation du processus commun (en s’appuyant sur la
représentation des composants en sous-processus internes ou externes)
donne une vision globale claire du processus commun. Le niveau de
granularité dépend à la fois de l’objectif de la modélisation et des détails
techniques liés à la mise en œuvre du processus métier concerné.
Dans les paragraphes précédents, nous avons expliqué notre
vision sur le processus commun et sa structure en fonction de mode
d’interaction commerciale. En outre, nous avons présenté les différentes
notions de l’intégration de la chaîne logistique par le biais du processus
commun. A ce stade de notre travail, nous présentons une feuille de
route vers la mise en œuvre d’une architecture cadre permettant la mise
en œuvre du processus commun.
Réception de
commande CRM
Sous-processus interne Sous-processus interne Sous-processus externe
Amener produire livrer
Entreprise A
Remplir la
commande
Inspection de
livraison Paiement
Entreprise B Entreprise C
Transporteur
Mayyad JABER 90
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
5.4 Feuille de route pour une architecture cadre
Une véritable collaboration est bien plus qu’une simple exposition des
processus de fabrication et des services offerts par un partenaire de la
chaîne logistique. Le processus commun doit aller au-delà d’un échange
commercial simple. Il doit faciliter la collaboration interentreprises de
manière à ce que les partenaires partagent leurs ressources avec comme
objectif d’obtenir des gains mutuels. Dans ce travail, l’architecture cadre
permet de partager les informations et orchestrer la collaboration
interentreprises. Notre approche repose sur une vision globale de la
collaboration interentreprises à l’aide d’un support informatique
distribué. Ce cadre est conçu afin de permettre aux entreprises de tirer
avantage de la collaboration. Il offre les facilités nécessaires allant de la
découverte de services en passant par le processus de négociation
jusqu’au support des processus interentreprises [Jaber et al., 2005].
Le but de notre architecture cadre est d’offrir une plate-forme
pour la modélisation et la mise en œuvre des processus communs. Pour
supporter les évolutions potentielles au niveau organisationnel, notre
architecture cadre est conçue de manière ouverte : elle est définie
comme un squelette d’architecture pouvant intégrer les activités et les
systèmes d’information patrimoniaux des partenaires (Figure 5-2).
Les processus communs sont bâtis à partir des sous-processus
internes des partenaires. Il s’agit de définir la logique de composition et
les messages à échanger entre les composants du processus commun.
Les systèmes d’information supports pour les sous-processus sont
habituellement hétérogènes. A cette fin, un processus d ’interfaçage doit
être mis en place afin de garantir l’interopérabilité entre les sous
processus composant le processus commun.
Mayyad JABER 91
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 5-2 Feuille de route pour l’architecture cadre
5.4.1 Organisation d’un Workflow global : Composition du processus
commun
Le but de notre travail est de proposer une architecture cadre pour
permettre à des processus métiers distribués d’automatiser leur
communication malgré le fait que leurs systèmes informatiques supports
soient distribués et conçus indépendamment. Afin de supporter
l’automatisation des processus métiers interentreprises, nous appliquons
les techniques de Workflow. Cela offre des facilités pour garantir le bon
déroulement du processus commun durant la phase d’exécution.
Le processus de Workflow peut être défini comme
« l’automatisation des procédures où l’information et les tâches passent
entre les participants, selon un ensemble des règles prédéfinies, afin
d’atteindre un objectif commun de business » [Hollingsworth, 1995],
(page 6).
Lorsqu’on recourt à une approche de type Workflow pour
définir la logique de processus commun, la démarche d ’intégration est
Mayyad JABER 92
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
encore plus poussée. Le Workflow permet de déterminer non seulement
ce qu’il faut faire avec les informations échangées, mais comment le
faire.
Grâce aux techniques de Workflow, la composition du
processus commun est réalisée sans intervention sur les services locaux
des participants dans le processus commun. Le système d’information
local qui gère le processus privé ne sera pas concerné par la manière
dont la délégation de service est effectuée pendant le temps d ’exécution.
Le Workflow support d’un processus commun est constitué
d’un ensemble de processus et de règles de routage : il (le Workflow)
définit la séquence des tâches ou des processus, les règles de routage qui
doivent être suivies ainsi que les délais et les autres règles commerciales
mises en œuvre par le moteur de Workflow. La liaison entre les sous-
processus (gérés par des systèmes de Workflow ou par des applications
propres aux entreprises individuelles) est effectuée sous forme
d’échange de messages entre les entreprises participantes. Le processus
de liaison entre les processus distribués devrait être exécuté de manière
souple, sans intervention ad hoc sur les systèmes locaux du demandeur
et du fournisseur de service. Pour atteindre ce but, le gestionnaire du
Workflow global doit assurer l’intégration des sous-Workflows en dépit
des déférences dans leurs organisations. Pour cela, des adaptations
spécifiques pour supporter l’interopérabilité entre les sous-Workflow
sont requises. Ces adaptations sont expliquées dans le paragraphe
suivant.
5.4.1.1 Interopérabilité des Workflows
Les systèmes de Workflow traditionnels offrent un support pour les
processus de production, d’administration et de collaboration. Les
processus sont instanciés conformément aux modèles et formats
prédéfinis. Les systèmes traditionnels de Workflow peuvent contribuer
au processus d’intégration dans le cas où le Workflow global est
construit à partir de cadres formels. En revanche, ils n’offrent pas la
flexibilité nécessaire pour traiter les modifications fréquentes sur les
règles et les conditions dans le domaine de la chaîne logistique.
En effet, le problème avec les Workflow dans le domaine du
B2B est que le processus interentreprises ne peut pas être instancié à
partir d’un modèle de processus prédéfini mais il est plutôt modélisé
Mayyad JABER 93
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
comme un Workflow ad hoc (Figure 5-3 ). Par rapport aux Workflow
formels, les processus dans un Workflow ad hoc sont dérivés de modèles
génériques et peuvent être modifiés pour répondre à des besoins
spécifiques afin d’offrir la flexibilité nécessaire [Dittrich and Tombros,
1999].
Figure 5-3 (A) Workflow formel – (B) Workflow Ad hoc
Un Workflow ad hoc peut-être vu comme une orchestration non
prédéfinie de plusieurs activités (ou sous-processus) rassemblés afin de
réaliser un objectif prédéfini [Weber and Wild, 2005]. Un autre aspect
sur le Workflow ad hoc concerne la nature de son sous processus. En
effet, les tâches dans un Workflow ad hoc sont bâties selon
l’organisation du processus dans le monde réel et non pas selon un cadre
rigide. Cette contrainte impose une intégration manuelle afin de
connecter les différents Workflow distribués dans un Workflow global.
Cependant, dans le contexte de la chaîne logistique, les deux
types de Workflow (ad hoc et formel) coexistent ce qui demande une
approche pour les intégrer de manière dynamique.
5.4.1.2 Intégration des Workflows hétérogènes
Comme nous avons mentionné précédemment, les deux types de
Workflow, ad hoc et formel, coexistent ensemble dans le domaine de la
chaîne logistique. Il existe un besoin pour intégrer les deux types de
Workflow sans imposer la transformation du Workflow ad hoc vers un
Workflow formel.
Mayyad JABER 94
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Afin d’assurer l’agilité et de supporter l’intégration des
services, le cycle de vie du processus est intégré dans le système
support. Tout d’abord les processus sont conçus d’une manière
exploratoire. Puis les Workflows ad hoc résultants sont intégrés dans le
Workflow global pour supporter efficacement la phase d ’exploitation.
Enfin, le Workflow global est adapté dans un processus de ré-
engineering en permettant aux composants de Workflow ad hoc
d’évoluer selon les changements de conditions. Ce système support
prend donc en compte à la fois les Workflows ad hoc et formels.
Dans ce travail, une méthode formelle d’assemblage pour les
sous-Workflow est présentée. Cette méthode permet l’intégration de
plusieurs sous-Workflow dans un Workflow global quel que soit leur
type. Pour cela nous utilisons un médiateur entre les différentes parties
du Workflow global. Le médiateur assure l’interopérabilité entre les
sous-Workflows hétérogènes (y compris ceux qui ne sont pas nativement
supportés par un système d’information) [Jaber et al., 2006a].
5.4.1.3 Le médiateur
L’objectif principal du médiateur est de supporter le processus de
composition du Workflow global en offrant des connecteurs standard
entre les processus constituant le Workflow global.
Le médiateur est composé d’une boîte de réception (inbox) et
d’une boite de renvoi (outbox) destinées à la conservation de données
relatives aux processus en cours de traitement par une instance du
Workflow global (Figure 5-4). Afin de maintenir les traces de plusieurs
instances qui fonctionnent simultanément, le médiateur est doté d’une
pile de descripteurs des processus en cours. Les descripteurs sont décrits
comme des tuples contenant des informations sur le contexte du
processus concerné : Process_ID, Process_Status,
Process_Predecessor(s) et Process_Successor(s). Les informations
associées à chaque processus supervisé par le Workflow global sont
mises à jour en continu. Les informations recueillies dans la pile
constituent une ressource importante à analyser et ensuite à employer
comme données entrantes pour le processus de réingénierie de
Workflow global.
Comme nous l’avons mentionné précédemment, les tâches
"manuelles" (c'est-à-dire non supportées informatiquement) sont
Mayyad JABER 95
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
susceptibles d’être intégrées dans un Workflow administratif. Pour cela
le médiateur prend en charge les deux types de ports de communication
API (Application Program Interface) et GUI (Graphical User Interface)
comme illustré dans la Figure 5-4. L’utilisation du médiateur comme un
connecteur offre une approche standard pour la construction des
Workflows formels globaux combinant à la fois des Workflows formels
et ad hoc. Ainsi, grâce au médiateur, les Workflows globaux conservent
la flexibilité nécessaire pour la reconfiguration des processus métiers à
la volée. En outre, l’interconnexion des sous-Workflows hétérogènes par
le biais du médiateur offre une approche standardisée pour la
reconfiguration et la réingénierie des Workflows à base de services.
Figure 5-4 Rôle du Médiateur
Le processus implémenté dans un médiateur comporte trois étapes :
1. Réception d’une requête (pour exécuter un processus ou un sous-
Workflow) arrivée dans la boite de réception. Ensuite la requête est
transmise soit au Workflow ad hoc via l’interface GUI ou bien au
Workflow formel via l’API de médiateur
2. En attendant les résultats issus des sous-Workflows adéquats,
l’instance du processus concerné (avec les informations sur le
contexte de l’exécution) est gardée dans la pile des descripteurs des
processus.
Mayyad JABER 96
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
3. Expédier les résultats vers la boite de renvoi en utilisant soit l’API
pour le Workflow formel soit le GUI pour le Workflow ad hoc.
Afin de clarifier le rôle de médiateur pour l’intégration des
Workflows ad hoc, nous introduisons dans le paragraphe suivant une
étude de cas de e-approvisionnement.
5.4.1.4 Etude de cas : e-approvisionnement
À titre d’exemple nous considérons un Workflow d’approvisionnement
qui représente le traitement d’un bon de commande créé par un client
afin d’acheter un produit d’un fabricant. Ce produit est composé de deux
matières premières MP1 et MP2. MP1 est fournie par un fournisseur F1.
MP2 est fournie simultanément par deux fournisseurs F2, F3. Afin de
remplir la commande, une instance d’un Workflow est initiée par le
fabricant. Ce Workflow pourrait englober d’autres Workflows gérés par
les fournisseurs du fabricant. Après la validation du bon de commande,
la tâche suivante est de vérifier si la commande peut être remplie
directement à partir du stock de fabricant. Dans ce cas, le fabricant
procède à la livraison directement. Dans le cas où le niveau de stock
pour le produit demandé ne permet pas la réalisation de lu bon de
commande, un processus de fabrication est nécessaire. Selon la capacité
de production et la réserve de matières premières MP1 et MP2, le bon de
commande pourrait être accepté ou rejeté comme l’illustre la Figure 5-5.
Afin de montrer le rôle du médiateur, nous nous concentrons
sur le cas où le bon de commande est accepté avec la nécessité
d’approvisionnement de matières premières MP1 et MP2. Avant que le
fabricant lance le processus de fabrication, un processus
d’approvisionnement de 2 matières premières (MP1 et MP2) est lancé.
Ce processus est réalisé en deux phases : la cotation (quotation) et
l’approvisionnement. Comme l’illustre la Figure 5-5, la partie de ce
système global de Workflow répartis entre les trois fournisseurs est un
Workflow ad hoc ; les entrées et les sorties de cette partie sont établies à
l’avance, alors que la structure interne n’est pas connue. Nous montrons
trois possibilités pour cette partie ad hoc du Workflow :
Mayyad JABER 97
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 5-5 Rôle de médiateur dans un e-approvisionnement
Mayyad JABER 98
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
1. Les trois fournisseurs de matières premières F1, F2 et F3 sont
contactés en parallèle pour fournir un devis. Dans ce cas, le fabricant
attend des réponses des trois fournisseurs. En fonction de ces
réponses, le fabricant décide de rejeter ou d’accepter le bon de
commande. Le fabricant notifie le client en cas de rejet ou alors
procède au processus de fabrication.
2. Les fournisseurs F1 et F2 sont contactés en parallèle pour fournir un
devis puis F3 est contacté en cas de défaillance de F2 ou en cas
d’une réponse de F2 qui ne convient pas. Cette configuration de
Workflow ad hoc est effectuée lorsque le fournisseur F2 est
privilégié.
3. Les trois fournisseurs sont contactés pour fournir un devis de façon
séquentielle, c’est-à-dire l’un après l’autre.
Au cours de la phase d’exploration, le choix entre ces trois
possibilités peut être effectué manuellement. Le rôle du médiateur est de
déterminer quel choix doit être exécuté en fonction des informations
fournies dans la boîte de réception. Comme indiqué précédemment
(section 5.4.1.3), le médiateur recueille des informations sur chaque
instance du Workflow ad hoc exécuté dans la phase d’exploitation. Ces
informations sont analysées dans la phase de réingénierie afin de choisir
la configuration la plus adéquate de Workflow ad hoc à exécuter selon le
contexte de processus métier.
L’utilisation du médiateur pour la construction du Workflow
global permet de résoudre le problème de l’interopérabilité entre les
sous-processus distribués quelle que soit leur organisation. Les sous-
processus composants du Workflow global sont supportés
habituellement par des systèmes d’information hétérogènes. En
conséquence, des facilités permettant l’interopérabilité entre ces
composants doivent être mises en place afin de mettre en œuvre le
processus commun. A cette fin, les processus internes, dédiés à la
manipulation des tâches locales, doivent être transformés en services
publics accessibles par des entités de business externes comme les
fournisseurs, les clients ou les prestataires de services logistiques. Ces
services publics, associés à un profil commercial, sont ensuite publiés
dans un registre public afin que les autres entités de business intéressées
par des services spécifiques puissent les trouver. Dans les paragraphes
Mayyad JABER 99
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
suivants, nous décrivons en détail les démarches restantes de la feuille
de route.
5.4.2 Interopérabilité et externalisation des processus métiers internes
Quand il s’agit de l’automatisation de collaboration interentreprises, une
attention particulière devrait être portée sur l’externalisation des
processus métiers internes. Une étape essentielle pour bâtir le processus
commun et renforcer la collaboration interentreprises est de rendre les
processus privés et, par conséquent, une partie du système d’information
de l’entreprise, accessibles par les autres partenaires. Les processus
privés sont externalisés (dans le sens où ils sont rendus visibles et
accessibles vis-à-vis les entités de business externes) par le biais de
services Web. Ces derniers constituent les interfaces de communication
entre les systèmes patrimoniaux. Les processus communs peuvent être
construits en composant les services Web associés aux processus privés,
menant à un échange formel basé sur une séquence de messages et de
données selon un format prédéterminé, (Figure 5-6) [Jaber et al., 2005].
Figure 5-6 Processus commun à base de services
Mayyad JABER 100
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Les processus communs sont établis lors de la phase de
négociation, réalisée selon des protocoles de négociation décrits grâce à
FLBC (Formal Language for Business Communication). Ce langage
permet aux applications distribuées de communiquer par des messages et
des protocoles signifiant pour l’établir les termes et les conditions du
contrat [Tan and Thoen, 2002]. Ensuite, ces contrats enregistrés dans un
référentiel seront utilisés pour automatiser (par le biais des systèmes de
gestion de Workflow) et surveiller l’exécution du processus commun
entre les partenaires.
Par exemple, un processus support à la génération d’un bon de
commande (ou Purchase Order - PO) peut être activé via le système de
gestion de production. Dans un système traditionnel, le bon de
commande est imprimé et envoyé manuellement par des moyens de
communication habituels : fax, courrier ou en tant que document attaché
envoyé par courriel au fournisseur. Ce dernier valide cette commande,
vérifie le niveau de stock, enregistre les informations pertinentes dans
les applications appropriées. Le traitement de cette commande par le
fournisseur se termine par la génération du bon de livraison et ensuite
par le processus de facturation.
Dans une architecture orientée service, plusieurs services
supports sont mis en œuvre afin de renforcer la communication entre les
briques applicatives (services de sécurité, de supervision, d’accès). A ce
stade du travail, nous nous intéressons aux services d’accès afin d’offrir
les canaux interopérables pour l’échange de données interentreprises.
Une architecture orientée services s’appuie sur des composants
modulaires. Il s’agit des services d’interopérabilité qui sont associés aux
processus internes dont l’objectif est de faciliter les échanges entre les
différents systèmes d’information au sein de la chaîne logistique. La
coordination du processus commun consiste en l’assemblage des
services distribués proposés par les partenaires. Dans notre architecture,
chaque service Web possède deux façades : frontal et dorsal (Figure
5-7). Les façades dorsales seront mises en œuvre en utilisant des
techniques d’interfaçage adéquates selon la nature des systèmes
patrimoniaux. En revanche, les façades frontales des services Web
possèdent les mêmes techniques d’invocation. Ceci offre une solution au
problème de l’interopérabilité en ce qui concerne les appels des services
effectués par les applications des partenaires. Ceci est réalisé en se
Mayyad JABER 101
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
basant sur un protocole d’invocation entre les services et l’échange de
messages normalisés. En effet, l’invocation de services est réalisée grâce
au SOAP en échangeant des messages de données structurés selon
l’interface du service et codés en XML. Afin d’intégrer les facilités de
systèmes de gestion de transactions, nous proposons l’utilisation de Wf-
XML avec un format commun de données pour garantir
l’interopérabilité syntaxique entre les services distribués. Il s’agit des
messages proposés par la coalition de systèmes de Workflow (WfMC)
comprenant les informations nécessaires pour l’invocation et l’exécution
des services participant dans le processus commun.
Afin de garantir le bon fonctionnement du processus commun,
les messages échangés doivent être traités de sorte qu ’ils soient
compréhensibles par les différents systèmes patrimoniaux des
partenaires. Dans notre architecture cadre, un traitement spécifique pour
l’interopérabilité des données est introduit dans le Chapitre 6.
Figure 5-7 Le rôle de services Web comme des interfaces
Après avoir externalisé les processus privés par la définition
des interfaces grâce à la technologie des services Web, les services
doivent être publiés dans un registre afin d’être découverts et invoqués
par d’autres entreprises par le biais du Web. Ceci est réalisé en utilisant
le langage WSDL (Web Services Definition Language). Ce langage
permet la description des entités de business et des services Web
associés. Le WSDL décrit les services comme un ensemble de points
terminaux capables de traiter les messages entre partenaires. Ces
Mayyad JABER 102
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
messages contiennent des informations orientées document ou procédure
portant sur trois volets : identification des entreprises, secteur d’activité
et informations techniques liées aux services exposés [Jaber et al.,
2005].
Les facilités d’un registre UDDI permettent d’enregistrer et
modifier les services. En outre, cette interface fournit des fonctionnalités
pour vérifier si un partenaire possède un service Web avec une interface
particulière. En conséquence, une entreprise peut trouver des entreprises
partenaires potentielles dans un secteur donné, pour un type de service
donné, avec la possibilité d’accéder aux informations techniques
exposées par le biais des services Web associés aux entreprises
recherchées. Toutefois, le registre UDDI n’offre pas toutes les
fonctionnalités nécessaires pour la découverte de services. En effet, le
mécanisme de découverte ne comporte pas de processus permettant de
trouver les entreprises qui peuvent offrir un produit ou un service
spécifique à un prix donné ou les entreprises qui se trouvent dans un
périmètre géographique précis (c’est-à-dire incluant des informations
sémantiques sur les propriétés des services). C’est pour cela que nous
mettons en place un moteur de recherche qui permet aux entreprises de
trouver des partenaires appropriés en se basant sur les informations
sémantiques incluses dans les documents échangés Figure 5-8. Le
moteur de recherche exploite les facilités offertes par les APIs de
découverte des services UDDI. Il est chargé non seulement de trouver
des entreprises avec des produits appropriés, mais aussi de vérifier la
compatibilité technique des interfaces proposées par les services exposés
dans le registre UDDI.
Les résultats de la recherche peuvent être filtrés pour permettre
de choisir les entreprises adéquates avec des services compatibles du
point de vue technique et plus particulièrement en ce qui concerne
l’interopérabilité syntaxique et sémantique des messages à échanger. En
outre, les informations sur les services élus sont sauvegardées dans un
registre historique, stocké localement pour constituer une base de
processus avec lesquels de futurs résultats de recherche pourraient être
comparées et plus particulièrement, lorsque ces services sont associés
avec des informations recueillies durant la phase d’exécution. À titre
d’exemple, prenons un service qui encapsule un processus de livraison.
Une comparaison entre le délai de livraison annoncé par le service et le
Mayyad JABER 103
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
délai de livraison réel peut être effectué afin d’évaluer la fiabilité du
service. En s’appuyant sur ces informations, le processus de ré-
ingénierie du processus commun peut-être amélioré en offrant une base
pour sélectionner les services les plus efficaces vis-à-vis des critères
présidant à la création du processus commun [Jaber et al., 2005].
Figure 5-8 Sélection de services intégrant un registre local destiné à améliorer
le processus de sélection
5.5 Conclusion
La nature flexible de la chaîne logistique impose un système support
agile pour répondre aux besoins d’évolutivité. Le processus commun
peut comporter à la fois des activités liées aux affaires à la volée et des
activités de collaboration de type long terme. Ceci implique une
intégration type "couplage lâche" du processus interentreprises.
L’intégration de la chaîne logistique est réalisée par l’échange des
informations entre les partenaires de manière souple et efficace.
L’organisation du processus commun prend alors une place importante
afin de répondre aux exigences de flexibilité et évolutivité dans le
contexte de la chaîne logistique. A cet effet, une architecture cadre
permettant la mise en œuvre des processus commun est indispensable.
Dans ce chapitre, nous avons présenté les différentes étapes d ’une
feuille de route pour l’architecture cadre. Cela a été réalisé en se basant
sur les concepts du processus commun et de Workflow global. Les
Mayyad JABER 104
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
notions concernant l’assemblage des sous-Workflow sous un Workflow
global ont été clarifiées au niveau organisationnel. Pour ce faire, un
traitement spécifique a été présenté afin de permettre l’intégration des
sous Workflows hétérogènes.
Le Workflow global offre un support standardisé pour
l’automatisation du processus commun. Le moteur du Workflow global
est un élément de base dans notre architecture cadre. Nous allons
présenter en détail l’organisation du moteur de Workflow global ainsi
que les rôles de ses composants dans l’interconnexion de Workflows
distribués. Ensuite, nous introduisons le concept de connecteur comme
un moyen standard permettant un processus automatisé d’interconnexion
pour les sous-Workflows constituants le Workflow global.
Afin de permettre l’interconnexion entre les systèmes
patrimoniaux des partenaires, les processus privés sont associés avec des
services Web et ensuite publiés dans un registre global afin de faciliter
leur invocation par d’autres services. Outre le registre global, Nous
avons montré le besoin d’un registre local afin d’améliorer le processus
de ré-engineering du processus commun (section 5.4.2). Nous
développons notre vision concernant la gestion des annuaires des
services avec deux types de registre global et local et un mécanisme de
synchronisation entre ces registres.
L’invocation des services publiés dans l’annuaire distribué est
effectuée par le biais des messages de données échangés entre les sous-
processus distribués. Afin de garantir l’interopérabilité de données
échangées, nous proposons un traitement spécifique basé sur des objets
métiers comme un moyen d’encapsulation des données adapté pour le
domaine métier.
Mayyad JABER 105
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 6 L’architecture cadre
6.1 Introduction
Dans les systèmes traditionnels, les solutions d’intégration sont souvent
établies selon une logique point-à-point en utilisant des APIs appropriés.
Bien que de nombreux systèmes patrimoniaux s’appuient sur des
techniques similaires, leur structures sont assez différentes (section
4.3.3). Afin d’éviter cette logique point-à-point, nous avons présenté une
définition d’un processus commun intégrant les différents systèmes
patrimoniaux qui appartiennent aux partenaires de la chaîne logistique.
La composition du processus commun est basée sur l’assemblage des
sous-processus distribués sous un Workflow global. A cet effet, nous
présenterons dans ce chapitre une architecture cadre permettant la
construction du Workflow global avec les facilités nécessaires pour
garantir le bon fonctionnement du processus commun. Nous allons
détailler les composants de l’architecture cadre et le mode de
fonctionnement. Comme nous l’avons déjà expliqué, l’assemblage du
processus commun est basé sur l’échange de données entre les sous-
processus distribués. Afin de résoudre le problème de l’interopérabilité
au niveau des données, des adaptations spécifiques, sont présentées à la
fin de chapitre.
6.2 L’architecture globale
Le cadre proposé supporte l’intégration dynamique pour les systèmes
patrimoniaux en se basant sur les processus privés et un Workflow
global. Ce cadre est destiné à résoudre les problèmes issus de
l’intégration de systèmes hétérogènes dans l’environnement distribué de
l’Internet. La Figure 6-1 montre la structure globale du cadre. Dans ce
cadre, quatre dispositifs sont retenus : moteur de Workflow,
Mayyad JABER 106
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
connecteurs, un registre de services local et un registre de services
global. Notre objectif est de proposer les facilités nécessaires pour la
coordination entre les services constituant le processus commun [Jaber,
2004]. Comme nous l’avons déjà expliqué, les services distribués sont
interconnectés par les invocations réalisées grâce à SOAP pour échanger
les messages de type Wf-XML. Il s’agit des messages proposés par le
WfMC qui contiennent des informations sur l’adresse URI,
l’acheminement, mais aussi les données nécessaires pour l’invocation du
service demandé (voir section 6.2.3.3).
Figure 6-1 Un cadre générique de système d’information coopératif
Quand un système de Workflow local chargé d’exécuter une
tâche décide de faire appel à un service pendant l’exécution d’un
processus, le moteur de Workflow doit déterminer si le système local
peut fournir le service demandé. Dans ce contexte, le moteur de
Workflow devrait avoir une architecture flexible et standardisée pour
sélectionner et lier les services associés aux sous-processus durant la
phase d’exécution. Lorsque le moteur de Workflow constate que le
système local ne peut pas fournir le service, il invite le connecteur à
trouver un service externe approprié dans les registres de services et
délègue au connecteur l’exécution de ce service. Dans ce contexte, le
Mayyad JABER 107
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
moteur de Workflow fournit un service transparent pour l’utilisateur au
sujet des sous-processus. Après avoir déterminé le nom du service
externe retenu (selon le mécanisme expliqué dans la section 5.4.2),
L’utilisateur ou le demandeur de service peut invoquer ce service en
fournissant seulement son nom. Ceci est réalisé sans avoir connaissance
par le demandeur du service de l’endroit où ce sous-processus est
implémenté.
Le connecteur choisit le sous-processus approprié en
recherchant dans le registre de services local avec un nom de service
donné. Une fois que le système de Workflow ou l’application
d’entreprise est trouvé, le connecteur demande au système choisi de
fournir le service. Il l’invoque grâce au protocole d’accès SOAP
permettant d’échanger des messages basés sur le format Wf-XML. Ceci
signifie que le connecteur fournit un service de localisation transparent
pour les sous-processus externes. Par conséquent, ce cadre permet au
demandeur du service d’employer tous les sous-processus externes
comme un sous-processus interne indépendamment de l’organisation, du
lieu, et de la plate-forme d’exécution. Des messages XML sont
employés pour communiquer avec d’autres systèmes de Workflow, avec
les applications propres de l’entreprise et pour accéder au registre de
services global afin de mettre à jour le registre de services local. Les
messages de Wf-XML peuvent être transmis via divers protocoles de
communication qui seront sélectionnés en fonction des besoins précis.
6.2.1 Organisation du moteur de Workflow global
Parmi les composants principaux du cadre, le moteur de Workflow joue
un rôle important dans ce cadre. Il devrait pouvoir décider si un service
peut être exécuté par le système local. Une fois qu’il décide que le
système local ne peut pas fournir un service, il crée un pilote de
Workflow pour contrôler le sous-processus externe et délègue le service
au connecteur pour commencer le sous-processus externe.
Le moteur de Workflow se compose de cinq éléments
principaux. Parmi ceux-ci : le demandeur de Workflow, le pilote global
et le générateur local sont instanciés lors de l’initialisation du système.
Le pilote de Workflow et le pilote de tâche sont instanciés au moment de
l’exécution répondant aux demandes de l’instance du demandeur de
Mayyad JABER 108
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Workflow. Les fonctionnalités de chaque élément sont définies comme
suit (Figure 6-2) :
Figure 6-2 Liens entre les composants du moteur de Workflow
Demandeur de Workflow : il joue le rôle d’une interface soit entre les
participants et le moteur de Workflow pour créer une instance de
processus, soit entre le pilote associé à une tâche décomposée en sous-
flux et le pilote global pour créer une instance de processus de pilotage
et du sous-processus de Workflow. Dans le cas où le système local
fournit le service pour un système externe, le connecteur considère le
Demandeur de Workflow comme une interface pour le pilote global et le
pilote associé au système de Workflow externe considéré.
Pilote Global : cette classe dirige le moteur de Workflow et contrôle la
création du pilote de Workflow et des pilotes associés aux tâches. Ce
processus permet de créer l’instance de Demandeur de Workflow au
générateur local approprié. Il sélectionne également le type de pilote de
Workflow adapté en fonction des données issues du contexte (contenant
en particulier le nom du service et le nom du processus correspondant au
pilote de la tâche concerné en recherchant les informations nécessaires
dans le registre interne de services). Si l’un des processus nécessaires
n’existe pas à l’intérieur du système local, le pilote global demande au
générateur local de créer un pilote de Workflow externe et envoie les
Mayyad JABER 109
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
données sur le contexte à ce pilote qui contrôlera le sous-processus
externe.
Générateur Local : ce module crée les instances des pilotes associés
aux tâches et au Workflow selon la demande de création venant du
pilote global. Cette demande contient l’information nécessaire sur les
instances des pilotes associés aux tâches et au Workflow. Dans le cas
d’un sous-processus externe, cette demande permet de créer seulement
le pilote de Workflow, qui contrôlera les sous-processus externes.
Pilote de Workflow : ce module est responsable du contrôle des pilotes
associés aux tâches de ce processus de Workflow. Il ne s’occupe pas des
données spécifiques d’une tâche mais seulement des données partagées
au niveau du processus de Workflow (nom du processus, nombre de
tâches, références des pilotes associés aux tâches...). Le P ilote de
Workflow est associé à deux instances différentes : le Pilote de
Workflow interne gère les processus internes et le Pilote de Workflow
externe contrôle les processus externes en utilisant des connecteurs.
Pilote de tâche : c’est le responsable du contrôle de la tâche associée
dans un processus de Workflow. Le Pilote de Tâche possède toutes les
données nécessaires pour pouvoir gérer la tâche.
Après avoir présenté les composants du moteur de Workflow
global, nous traitons l’interconnexion de gestionnaires des sous-
workflows constituant le Workflow global.
6.2.2 Interconnexion de gestionnaires de Workflows distribués
Afin de supporter l’automatisation de la composition du Workflow
global, nous introduisons le concept de connecteur dont le rôle est de
relier les composants distribués du Workflow global via l’Internet
(Figure 6-3). Pour une entreprise prise individuellement, il s’agit d’une
passerelle mandataire pour la communication avec les systèmes de
Workflow externes. En effet, le connecteur ne fait pas partie des
éléments du moteur de Workflow. Il est chargé de décider le sous-
processus externe approprié en fonction des données de contexte du
pilote de Workflow en recherchant le service convenable dans le registre
Mayyad JABER 110
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
de services local. Dans le cas d’un fournisseur de service, le connecteur
invite le demandeur de service à créer le pilote de Workflow et
l’instance du processus correspondant au service demandé. Il représente
le système externe pour communiquer avec le PW.
Dans l’approche orientée objet, la délégation est une manière
générique qui permet d’étendre le comportement d’une classe en
appelant une méthode issue d’autres classes au lieu d’hériter cette
méthode de ces autres classes. Le connecteur est conçu pour être
raccordable à tous les systèmes de Workflow. C’est un intergiciel qui
repose sur le concept de délégation. Le connecteur permet ainsi de
déléguer un service du système local aux autres systèmes.
Habituellement l’objet connecteur est un objet qui reçoit les appels des
méthodes au nom d’un autre objet. Dans notre cadre, cet objet
connecteur envoie et reçoit des messages XML au nom du moteur de
Workflow. C’est-à-dire que le connecteur encapsule d’autres systèmes
de Workflow ou des applications propres à l’entreprise et les lie
dynamiquement au système local de Workflow. Le processeur de Wf-
XML dans le connecteur traduit les invocations de méthode (en langage
de programmation) sous forme de messages de Wf-XML et inversement.
Le connecteur possède des interfaces, une couche de service, un
processeur XML, un service de message de type Java JMS (Java
Messaging Server), et une interface vers le serveur web. Les interfaces
internes sont définies pour le moteur de Workflow. La couche de service
se compose des instances d’application. C’est l’application en cours
d’exécution qui contrôle les messages de demande et de réponse XML.
La Figure 6-3 montre le positionnement du connecteur, du serveur web,
et du système de Workflow.
Les connecteurs associés aux systèmes globaux de Workflow
ou aux applications de l’entreprise peuvent être construits par ces
mêmes systèmes. Ces connecteurs doivent avoir des équipements qui
peuvent traiter les messages utilisant le standard XML et traduire les
données passées dans leur propre format.
Mayyad JABER 111
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 6-3 Vue conceptuelle du connecteur.
6.2.3 Composition du Workflow global
Afin d’automatiser le processus d’échange d’information au sein de la
chaîne logistique, nous avons proposé la mise en place d ’un Workflow
global composé des sous-processus distribués. Pour cela, une interface
doit être mise en œuvre afin que le bon de commande (ou tout autre
document issu du système d’information de l’un des partenaires) puisse
être inséré dans le système d’information d’une autre entreprise sans
nécessiter d’intervention humaine. Ainsi, cette interface doit permettre
d’échanger des documents entre les différents partenaires en dépit de
l’hétérogénéité potentielle de leurs systèmes d’informations. La
complexité du système d’information qui supporte le processus commun
peut être réduite avec l’organisation modulaire de composants. A cet
effet, l’utilisation de services Web offre une intégration souple avec un
couplage lâche. C’est pourquoi nous mettons en œuvre cette interface
par le biais de services Web. Les services Web offrent une solution
technique indépendante de la plateforme et des interfaces qui permettent
la communication avec d’autres applications à l’aide de protocoles
associés à l’Internet (section 4.5). Comme nous l’avons déjà mentionné,
Mayyad JABER 112
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
les services associés aux processus internes sont publiés dans un
annuaire distribué. En ce qui suit, nous présentons notre approche pour
la publication des services ainsi que la gestion de l’annuaire distribué.
6.2.3.1 Publication des services associés aux processus internes
Le registre de services est un dispositif de stockage qui contient
l’information sur les processus et les systèmes de Workflow. Beaucoup
de cadres d’EDI ont des possibilités semblables qui incluent des
informations sur d’autres systèmes d’EDI. Par exemple, l’ebXML et le
RosettaNet disposent d’un registre de services et d’un dictionnaire
principal. Dans notre cadre, au lieu d’un dépôt simple, le registre de
services est divisé en deux niveaux : global et local afin de faciliter la
recherche de services. Cette recherche utilise les messages XML. Pour
limiter les risques d’échec, les recherches sont menées à la fois sur les
registres locaux et sur le registre global.
Le registre de services local est contrôlé par un pilote propre et
est placé localement dans l’organisation. Les services locaux du registre
de services local présentent l’information associée aux applications de
l’entreprise. Le registre de services global doit disposer d’assez
d’informations pour qu’un connecteur puisse construire les messages
XML nécessaires pour le service considéré. Ainsi, il devrait fournir non
seulement les noms des services disponibles et les identifiant des
processus mais également la liste des noms et types de données pour
chaque service.
Les fournisseurs de service, qui veulent annoncer leurs
services, peuvent enregistrer, mettre à jour et supprimer les informations
concernant ces services dans le registre de services.
Les applications propres à l’entreprise enregistrent et mettent à
jour seulement le registre de services local avec leurs interfaces de
service. L’organisation distribuée pour les registres de services impose
d’un mécanisme de synchronisation entre le registre global et les
registre locaux. Puisque le nombre des mises à jour pour les services
dans les registres locaux est limité, nous traitons le risque d ’incohérence
des informations liées aux services dans les différents registres comme
une exception. Pour cela, le registre global doit interroger
périodiquement les registres locaux pour garantir la conformité des
informations liées aux services avec celles des registres locaux. Chaque
Mayyad JABER 113
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
fois que les informations dans le registre de services global sont
changées, ce registre diffuse cette modification vers les registres de
services locaux des autres entreprises.
Lorsqu’un système global de Workflow exécute un service,
plusieurs exceptions peuvent se produire si le registre de services global
ou local ne dispose pas de l’information nécessaire concernant le service
demandé, ou si l’information associée à la demande de service est
différente de celle définie dans l’interface de service utilisée dans le
système globale. A cet effet, un traitement pour l’incohérence entre les
registres locaux et le registre global est indispensable.
6.2.3.2 Gestion et synchronisation de l’annuaire distribué
Comme nous l’avons déjà mentionné, la contradiction entre les
informations sur les services peut se produire parce que le cadre proposé
maintient deux types de Registre d’Interfaces de Service : local et
global. En outre, l’information concernant les services externes n’est pas
accessible directement par le registre de services local. Ceci peut
conduire à deux situations d’exception concernant les informations sur
les services : « information non disponible » ou « information non mise
à jour » :
Non disponible : dans cette situation, il n’y a pas d’information sur
le service dans le registre. Cela peut se produire quand un service est
annulé ou remplacé par un autre service.
Non mis à jour : C’est la situation dans laquelle les systèmes locaux
de Workflow ou bien les applications d’entreprise ont modifié les
configurations de leurs interfaces de service dans le registre local.
Mais le registre global n’a pas été mis à jour.
Pour gérer ces exceptions et les situations contradictoires, nous
avons identifié quatre états possibles :
Non trouvé : Dans ce cas, l’information sur un service n’est pas
disponible. Le moteur local de Workflow attend une manipulation de
l’administrateur ou doit rechercher une autre interface de service en
utilisant des règles spécifiques.
Mayyad JABER 114
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Avorté : Dans ce cas, le fournisseur du service décide qu’il ne peut
plus accomplir le service demandé soit parce que le service a été
remplacé par un autre service ayant une logique de traitement
différente mais offrant une interface identique, soit lorsque d ’autres
types de problèmes surviennent lors de l’exécution (arrêt pour une
ressource…). Dans ce cas, le moteur local de Workflow attend une
manipulation de l’administrateur ou doit rechercher grâce à un
ensemble de règles spécifiques une autre interface de service.
Modifié : Dans ce cas, les processus internes ont été modifiés mais
sans impacter la logique de fonctionnement global (respect de la
logique de Business Process Reengineering) ni modifier les
spécifications d’interface. Dans ce cas, même si certaines tâches
sont omises, le processus global se déroule normalement. Seule
l’instance en cours d’exécution de ce processus est modifiée
(suppression des tâches qui n’apparaissent plus ou insertion de
nouvelles tâches).
Non accompli : Dans ce cas, les services sont identiques mais le
processus est remplacé par un modèle modifié. Le système global
doit avorter le processus courant, accomplir la substitution du
processus initial par le modèle modifié et recommencer l’exécution
avec le modèle modifié.
Dans les paragraphes précédents, nous avons présenté
l’organisation du Workflow global en se basant sur les services
distribués proposés par les partenaires de la chaîne logistique. La
composition du Workflow global est effectuée par le biais de
connecteurs qui assurent l’échange de messages entre les sous-
workflow. Les détails des messages échangés sont présentés dans le
paragraphe suivant.
6.2.3.3 Échange de messages métiers et coordination
Ces messages sont des éléments importants dans notre architecture. En
employant ces messages, le moteur de Workflow peut communiquer
avec d’autres systèmes et d’autres applications de l’entreprise via le
connecteur. Un message de Wf-XML se compose de trois parties :
Mayyad JABER 115
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Les informations liées au transport du message (WfTransport) :
contient les informations nécessaires pour l’acheminement du
message (protocoles utilisés et données permettant de définir
l’acheminement)
L’en-tête de message (WfMessageHeader) : contient l’information
utile pour les messages, tels que l’URI (Universal Ressource
Identifier), le sens du message (demande ou réponse), etc.
Le corps de message (WfMessgeBody) : inclut le nom de
l’opération, la demande de service et les données associées.
En vu de supporter l’interopérabilité entre gestionnaires de
Workflows, le WfMC a défini quatre opérations de Wf-XML :
CreateProcessInstance
GetProcessInstanceData
ChangeProcessInstanceState
ProcessInstanceStatChanged
Avec ces opérations associées aux messages Wf-XML, les
instances du processus commun peuvent être manipulées de manière
cohérente.
L’utilisation des techniques de Workflow proposées par le
WfMC permet de garantir le niveau d’interopérabilité requis entre les
sous-processus composant le processus commun. La gestion du
processus commun devient ainsi contrôlée par le gestionnaire de
Workflow global.
6.2.3.4 Principe de fonctionnement
La première étape est le processus d’initiation. Le processus principal de
Workflow est lancé par un client ou un demandeur de service en
invoquant le Demandeur de Workflow. Celui-ci délègue cette demande
au module de gestion des Pilotes Globaux qui demandent au Générateur
Local de créer le Pilote Global et les Pilotes de Tâche correspondan t à
l’instance des pilotes qui seront associés à l’instance du processus qui
sera exécutée. La création de ces pilotes est basée sur le modèle du
processus principal.
Mayyad JABER 116
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Après ce processus d’installation, le processus principal peut
débuter. Si un Pilote de Tâche associé à une tâche décomposée en sous-
flux prend en charge le contrôle du processus pendant l’exécution, le
même procédé d’installation est répété : le Pilote de Tâche de la tâche
associée à ce sous-flux invoque le Demandeur de Workflow pour créer
une instance du sous-processus approprié au moment de l’exécution.
Cette demande est basée uniquement sur les noms donnés aux services et
aux processus. Il n’y a pas besoin d’information détaillée sur le sous-
processus visé. Lorsque le Pilote Global reçoit cette demande du
Demandeur de Workflow, il décide si ce service peut être fourni par le
système local de Workflow. Dans ce cas, le Pilote Global invite le
Générateur Local à créer le Pilote de Workflow interne et les Pilotes de
Tâches correspondant. Lorsque le système local ne peut pas fournir ce
service, le Pilote Global invite le Générateur Local à créer seulement un
Pilote de Workflow externe. Ce Pilote de Workflow externe invitera un
connecteur à exécuter le sous-processus externe. Une fois terminé, ce
processus récursif d’installation, le Pilote de Tâche associé à la tâche
décomposée en sous-flux demande au Pilote de Workflow (interne ou
externe) de commencer l’exécution du sous-processus. Durant cette
phase d’exécution, l’échange de données entre les sous-processus joue
un rôle principal pour assurer l’interconnexion de composants du
processus commun. Afin de garantir l’interopérabilité au niveau des
données échangées, nous proposons un traitement spécifique à base
d’objets métiers.
Le Workflow global mis à disposition peut être considéré
comme une machine à transition d’états. Dans ce Workflow, les
différentes instances de processus ou d’activité changent d’état en
réponse aux événements externes (par exemple l’accomplissement d’une
activité) ou en fonction des décisions spécifiques prises par un moteur
de Workflow (par exemple, le routage vers la prochaine étape d ’une
activité dans un processus). Dans notre cadre destiné à supporter
l’interopérabilité entre les systèmes patrimoniaux, le Workflow global
est basé sur le modèle hiérarchique de décomposition des tâches en
sous-flux. Dans ce modèle, une sous-tâche dans un processus peut
représenter beaucoup de sous-processus alternatifs. Ces sous-processus
peuvent récursivement contenir des tâches décomposables en sous-flux
qui peuvent représenter plusieurs sous-processus alternatifs et points de
Mayyad JABER 117
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
contrôle associés. Ceci permet de choisir dynamiquement les sous-
processus appropriés au moment de l’exécution.
Ceci signifie que beaucoup de sous-processus peuvent être
hiérarchiquement liés dans un processus commun. Ainsi, la modélisation
de transitions d’état permet de représenter les états des instances créées
de ces sous-processus d’une manière dynamique. Le nombre d’instances
de sous-processus et d’instances de tâches de sous-processus qui
peuvent être créées n’est pas prédéfini d’avance. Il est déterminé
dynamiquement selon les données de contexte de la tâche.
Ce modèle permet de contrôler la création et la transition
d’états associés aux processus engagés, les conditions de branchement,
le flux de transition, l’acteur participant dans le processus de Workflow
ainsi que le lancement des applications basées sur les données du
Workflow sauvegardées dans la base de données globale. Les conditions
associées aux données du contexte déterminent les pré et post conditions
de définition des instances de processus. Ce modèle fournit les facilités
nécessaires pour contrôler dynamiquement la création de plusieurs
instances, à partir d’une définition de processus. Il contrôle l’utilisation
des données par les processus en cours. Il contrôle aussi les
cheminements suivis dans chaque instance en fonction des conditions de
branchement.
6.3 Traitement pour l’interopérabilité de données
Lorsque les entreprises coopèrent dans une chaîne logistique, il faut une
compréhension commune sur les processus métiers partagés. En outre,
l’échange d’informations entre l’ensemble des processus métiers exige
la portabilité des données à travers des applications hétérogènes. Des
patrons de modélisation sont nécessaires pour avoir des structures
partagées et rendre ainsi les données échangées entre les processus
d’entreprise plus facilement interopérables (en utilisant le même
modèle). Pour cela, nous proposons d’utiliser les objets métier avec le
modèle de référence pour le traitement réparti ouvert (Reference Model
for Open Distributed Processing : RM-ODP) (section 3.4.1) [Jaber et al.,
2006b]. Ceci offre une description normalisée de données dans les
systèmes qui supportent le traitement distribué des processus
hétérogènes en utilisant un modèle commun d’interaction.
Mayyad JABER 118
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
6.3.1 Les objets métiers
Quand il s’agit de la modélisation des composants de la chaîne
logistique, nous distinguons des entités (noms) et des activités (verbes).
Les entités sont des choses qui existent dans l’entreprise, soit
physiquement (un employé) soit virtuellement (une entreprise). Les
activités sont des choses qui arrivent dans l’entreprise. Les activités
utilisent les entités. Nous modélisons ces deux concepts comme des
objets. Habituellement les objets se différencient par leurs états et leurs
comportements. L’état d’un objet métier est caractérisé par les valeurs
de ses attributs. Le comportement est représenté par les actions que
l’objet est en mesure d’effectuer pour atteindre son objectif.
L’avantage de base de l’utilisation des objets métier est la
possibilité de masquer les ressources locales en les encapsulant dans des
objets métiers bien définis. Ce faisant, les entreprises contrôlent l’accès
à leurs ressources en accordant des privilèges d’accès pour les
partenaires appropriés. Les objets métier peuvent en outre être utilisés
pour définir un mécanisme permettant d’accorder des privilèges d’accès.
Dans notre approche, les objets métiers représentent les éléments de
base pour la mise en œuvre des services métiers interopérables.
6.3.2 Référentiel pour les objets métiers
Afin de supporter l’interopérabilité au niveau des données, nous
proposons la construction d’un référentiel pour sauvegarder les objets
métiers communs. Ainsi ces objets deviennent accessibles à tous les
partenaires dans la chaîne logistique (Figure 6-4).
Mayyad JABER 119
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 6-4 Objets métiers et composition de services
Les objets métiers peuvent représenter le monde réel d ’une
manière précise. En conséquence, ils servent à améliorer la
compréhension et la communication entre les développeurs de systèmes
et les personnes impliquées au niveau business. Dans le domaine de la
chaîne logistique, les objets métiers sont extraits à partir des entités
clients, produits, stocks, commandes, etc. La différence principale entre
les objets métiers et la programmation de logiciels orientés objet est que,
outre la description des attributs et des méthodes, les objets métiers
définissent la valeur ajoutée d’un objet dans un secteur de business et
que ces objets métier sont des composants sensibles au contexte. Par
exemple, un objet de programmation qui représente un client possède
comme attributs le nom, l’adresse, le numéro de téléphone, la personne
contact et d’autres informations liées au client. Néanmoins, ce n ’est pas
suffisant pour avoir une description claire du client. Dans un objet
métier associé au client, les personnels commerciaux cherchent à
évaluer le crédit de ce client, la date de sa dernière commande, l ’état de
son compte, les produits habituellement commandés par ce client, etc.
En d’autres termes, un objet métier associé à un client décrit le profil du
client ce qui définit la façon dont les activités du client devraient être
traitées, et la façon de le servir en fonction du contexte.
Mayyad JABER 120
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Dans notre approche, nous représentons les différents types
d’objets métiers par des acteurs (représentés par des classes), ressources
et rôles. Ces unités sont corrélées comme suit : un acteur joue des rôles
en exécutant des activités sur les ressources. La Figure 6-5 illustre un
exemple pour deux acteurs (Fournisseur, Client) qui héritent de la classe
(Entreprise). Chaque acteur joue un rôle (vendeur/acheteur) en exécutant
une activité (libérer/récupérer) sur la même ressource. L’utilisation de
ce mécanisme de séparation ou d’association entre les objets offre la
flexibilité nécessaire pour la maintenance du système. Quand une
modification est réalisée sur la classe "entreprise", les associations avec
les différents rôles restent valables du fait qu’elles sont mises en œuvre
séparément [Jaber et al., 2006b].
Figure 6-5 Association des objets métiers basée sur les rôles
Outre les objets métiers, des formats de données de référence
sont définis, comme par exemple le format associé à une "commande".
Les formats de données de référence sont utilisés pour garantir la
conformité sémantique entre les différents objets métiers quand ils sont
utilisés pour mettre en œuvre des instances d’objets par des partenaires
extérieurs à la chaîne logistique (affaires à la volée).
Mayyad JABER 121
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
L’utilisation de l’ontologie pour décrire les objets métiers
devient importante au sein de la chaîne logistique dans le contexte de
l’intégration. Les objets métiers devraient être interopérables et
interchangeables entre les systèmes d’information patrimoniaux [IST,
2005]. L’ontologie des objets métiers est utilisée quand un objet métier
approprié doit être utilisé de manière cohérente au sein d’une
organisation ou d’un groupe d’organisations. L’utilisation de l’ontologie
assure aussi l’ouverture et la liberté de représentation interne de sorte
que si un objet a deux différentes spécifications dans la chaîne
logistique, chacune de ces spécifications sera utilisée en proposant un
mécanisme de "mapping" basé sur une ontologie d’objets métier. Pour
cela, l’utilisation de schémas XML permet de structurer les objets
métiers selon l’organisation hiérarchique des objets dans l’ontologie.
Cela facilite la description flexible de l’existant par les partenaires sur
un format pivot pour faire la traduction entre les objets métiers
semblables. L’utilisation de l’ontologie représentée par un service
sauvegardé dans le registre global permet l’échange des données tout en
gardant la diversité des objets métiers représentant les structures des
données de partenaires. Les objets métiers jouent un rôle primordial
pour garantir l’interopérabilité dans notre approche. Cela est réalisé
partialement par l’encapsulation des ressources via des objets métier. La
gestion de ressources distribuées de manière souple mais efficace est
une condition indispensable afin de garantir le bon fonctionnement du
processus commun de la chaîne logistique.
6.4 Conclusion
Dans notre architecture cadre, le Workflow global est construit en
s’appuyant sur les applications patrimoniales (rendu visible et accessible
par le biais de services Web). L’application résultante peut avoir une
structure chevauche du fait des recouvrements partiels pouvant exister
entre les applications patrimoniales. En plus, l’exécution du Workflow
global peut nécessiter une longue durée avec de longues périodes de
veille. Cela est souvent dû aux applications patrimoniales exigeant des
interactions avec un acteur humain.
En outre, pour les systèmes de gestion de Workflow
traditionnels, les tâches (sous-processus dans notre modèle) peuvent être
Mayyad JABER 122
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
un travail humain ou bien un processus automatisé. Ces tâches sont
réalisées au sein de la même entreprise. En revanche, dans notre
architecture cadre, ces tâches sont associées à des services Web
distribués. Le Workflow distribué basé sur des composants (donc
construit à partir de services Webs répartis), doit intégrer des outils de
gestion de transactions dédiés à la gestion d’échec (que ce soit dû à des
pannes matériels ou aux défaillances de réseaux).
Dans un environnement à couplage lâche comme le web, il est
inévitable que ces applications qui sont construites à partir de
composants distribués, exigeront des moyens pour traiter les échecs
éventuels. En effet, les machines elles-mêmes sont susceptibles de
pannes ou bien les services distribués peuvent être déplacés, modifiés,
ou supprimés. Une technique pour améliorer la tolérance aux pannes est
l’utilisation du concept de transaction. Les transactions garantissent que
seulement les changements cohérents et stables auront lieu en dépit de
l’accès concourant aux ressources et des échecs éventuels.
Dans le reste de ce mémoire, nous allons développer notre
architecture cadre en intégrant un système de gestion de transaction qui
prend en compte la notion de gestion de ressources distribuées.
Mayyad JABER 123
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 7 Ressources distribuées et
gestion de transactions
7.1 Introduction
Dans le chapitre précédent, nous avons présenté l’architecture cadre
pour un système d’information distribué dédié à la gestion de la chaîne
logistique. L’enjeu de base est d’offrir une infrastructure capable de
contrôler l’exécution du processus commun interentreprises. Après avoir
présenté notre vision sur la composition du processus commun sous
forme d’un Workflow global, nous avons développé des solutions
adaptées pour résoudre les problèmes d’interopérabilité sur les différents
niveaux de l’architecture. Les sous-processus composants du processus
commun doivent échanger les données nécessaires en phase d’exécution.
Ces données venant de différents logiciels (naturellement hétérogènes)
ne sont pas directement interopérables. Pour y remédier, nous avons
proposé une solution à base d’objets métiers avec un référentiel pour
conserver les objets métiers communs. L’utilisation des objets métiers
offre une solution pour garantir l’intégrabilité au niveau des données.
Dans notre architecture cadre, nous avons présenté les
principes d’un système de collaboration distribué destiné à gérer les
échanges interentreprises pour augmenter les profits des partenaires dans
une chaîne logistique. Afin de garantir la flexibilité du système proposé,
nous avons organisé le processus commun en assemblant les processus
locaux comme des services autonomes. Ces services encapsulent des
ressources distribuées gérées par les gestionnaires de ressources locaux.
Cette encapsulation n’est pas suffisante en elle-même pour garantir une
gestion cohérente pour la réservation et l’accès aux ressources
distribuées. En effet, les ressources sont allouées aux et accessibles par
les différents partenaires de manière concourante. Ceci conduit
Mayyad JABER 124
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
potentiellement, en cas d’exception, à des états d’interblocage
(deadlock) et de résultats incohérents. En outre, l’exécution du
processus commun est soumise aux interruptions à cause des pannes
liées aux matériels ou aux logiciels. Pour cela, nous présenterons un
mécanisme de gestion de ressources et de transactions distribuées adapté
pour le de domaine de B2B. Nous organisons la manipulation de
ressources et l’exécution des transactions distribuées selon trois phases
principales : préparation, exécution et finalisation. En se basant sur cette
organisation, nous proposons une vision pour un processus commun
transactionnel. Il s’agit précisément de l’intégration de la gestion de
transactions distribuées afin de garantir le bon fonctionnement du
processus commun dans un environnement de couplage lâche tel que la
chaîne logistique. Nous avons adapté les propriétés des transactions
(ACID) (sections 3.5.1) afin de répondre aux exigences du système
d’information pour la chaîne logistique.
7.2 La gestion de ressources distribuées
Afin de fournir un mécanisme agile pour la gestion des ressources
distribuées, les exigences de qualité de service et les contraintes de
temps doivent être intégrées dans le processus d ’allocation et de gestion
de ressources. L’infrastructure de collaboration doit traiter des
événements imprévus, issus des pannes matérielles ou logicielles, qui
pourraient survenir durant la phase d’exécution. Cette infrastructure doit
aussi tenir compte de demandes externes d’accès aux ressources via le
système de communication. En raison de l’organisation distribuée multi-
Workflow prévue dans l’architecture cadre, les conflits et les blocages
liés aux demandes de ressources doivent être pris en compte. Un conflit
apparaît lorsque deux ou plusieurs autorisations d’accès sont accordées
en même temps pour une ressource donnée. Par conséquent, la
coordination d’accès aux ressources distribuées implique un système de
contrôle global pour la gestion des ressources permettant l’allocation
dynamique des ressources. Afin de clarifier ces notions, nous
introduisons un exemple issu du domaine de la chaîne logistique (Figure
7-1).
Quand le fabricant reçoit un ordre d’achat, il vérifie son stock
pour décider s’il peut fournir les produits commandés à partir de son
Mayyad JABER 125
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
stock. Si oui, il planifie la livraison, notifie le grossiste et attend pour un
message de confirmation de la part de grossiste. Si l’état du stock ne
permet pas de répondre à la commande, le fabricant fait un appel à son
plan de production afin de savoir s’il pourra répondre dans le délai
précisé par le grossiste. En plus, le fabricant doit aussi contacter les
fournisseurs de matières premières (fournisseur 1 et fournisseur 2) afin
de planifier un processus d’approvisionnement le cas échéant. Ainsi,
selon le plan de fabrication et la capacité de production, le fabricant
décide soit d’accepter la commande soit de la rejeter. Il notifie le
grossiste de sa décision.
Figure 7-1 Exemple de processus sur une chaîne logistique
Durant les différentes étapes de l’exécution du processus
commun, des périodes d’attentes (phases de négociations par exemple)
sont prévues. Ces périodes peuvent durer des heures, des jours voire
plus. Quand le fabricant propose une nouvelle date de livraison le
processus commun dédié pour le traitement de commande entre dans un
état d’attente pour la réponse du grossiste. Cette réponse peut être
positive, négative, ou absente (le fabricant ne reçoit aucun message de la
part de grossiste dans un délai prédéfini). La cause de cette absence de
réponse peut être une panne matérielle/logicielle ou bien une mauvaise
intervention humaine. Durant l’état d’attente, le fabricant garde les
ressources nécessaires pour répondre à la commande dans un état de
réservation afin de garantir la possibilité de pouvoir traiter la commande
dans le cas d’une confirmation de la part du grossiste. Le temps de
suspension du processus commun doit être gardé au minimum afin
d’éviter un état d’interblocage qui peut avoir lieu quand un autre
acheteur tente d’accéder aux mêmes ressources.
Fournisseur 1
Fournisseur 2
Fabricant
Grossiste
Transporteur
Flux de produits
Mayyad JABER 126
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Par ailleurs, et afin de garantir la flexibilité du processus
commun, le grossiste peut décider d’acquitter la transaction avec ou sans
l’engagement du transporteur. Si le grossiste décide que le sous-
processus de livraison est impératif, le processus commun ne peut pas
être exécuté sans confirmation du transporteur bien que la confirmation
du fabricant ait été reçue. La notion de sous processus impératif impose
de classifier les ressources distribuées selon leurs rôles dans le
processus commun. En outre, dans la phase de préparation, certains
participants prennent des mesures au niveau de leurs ressources
associées tandis que d’autres annoncent leur insuffisance. Dans ce cas,
un mécanisme d’annulation doit être appliqué en cas d’exception afin de
compenser les mesures prises par les participants qui ont déjà pris des
mesures de réservation de ressources. Les paragraphes suivants portent
sur la notion de classement de ressources et sur le mécanisme de gestion
de ressources offrant la possibilité de traitement d’exceptions.
7.2.1 Organisation de ressources distribuées
Pour allouer une ressource unique demandée par plusieurs demandeurs
de ressources concurrents, un mécanisme d’allocation des ressources est
nécessaire afin d’éviter les blocages potentiels. Ce mécanisme devrait
être capable de prendre en compte les priorités des demandes de
ressources. Les demandes autorisées sont envoyées par un générateur
d’autorisation au Mécanisme d’Allocation des Ressources (Figure 7-2).
Ensuite, le Mécanisme d’Allocation des Ressources organise ces
demandes dynamiquement selon leur priorité dans une file d’attente
(FIFO priorisée). Néanmoins, cette gestion des priorités ne permet pas
de gérer les processus dits d’urgence (impliquant des ressources et des
tâches préemptives). Il faut donc que le mécanisme d’allocation de
ressources puisse traiter les demandes d’urgence en libérant des
ressources déjà réservées [Ali et al., 2007]. Ceci impose d’intégrer des
facilités de retour en arrière (rollback). Cette notion de retour en arrière
sera détaillée dans la section 7.2.4.
Pour une demande d’accès autorisé, le mécanisme d’allocation
des ressources cherche à réserver les ressources nécessaires en
transmettant les ordres de réservation aux gestionnaires de ressource
concernés. A cet effet nous avons introduit deux primitives selon la
Mayyad JABER 127
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
priorité : pour une demande de priorité élevée, l’instruction de
réservation est "lock_R", et pour les autres cas l’instruction est
"reserve_R". Pour libérer une ressource réservée, le mécanisme
d’allocation des ressources lance l’instruction release_R qui sera
exécutée par les gestionnaires de ressources concernés. Les transitions
d’état de ressources sont décrites dans la section suivante.
Figure 7-2 Mécanisme d’Allocation de Ressources
7.2.2 Transition d’état d’une ressource
Afin de répondre aux exigences de cohérence et d’adaptabilité
nécessaires pour l’exécution du processus commun, chaque ressource est
associée à l’un des états suivants (Figure 7-3) [Ali et al., 2007] :
Disponible : signifie que la ressource est disponible et peut être
réservée.
Réservée : signifie que la ressource est réservée pour être engagée
dans un processus distribué et ne peut plus être réservée par d’autres
processus. Dans ce cas-là, une exception peut être traitée quand une
demande urgente est reçue.
Gestionnaire de ressource
Ressources
Demandeur de ressource
Demandes de ressources
Instructions de MAR État de ressource
MAR
Demande_ID
Fil d’attente
Mayyad JABER 128
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Verrouillé : la ressource est verrouillée et aucune exception ne peut
être acceptée avant la fin du processus.
Exécution en cours : la ressource est engagée dans l’exécution d’un
processus distribué. Aucune exception n’est acceptée avant la fin du
processus en cours d’exécution.
Figure 7-3 Transition d’état d’une ressource
7.2.3 Phases d’exécution
Pour tenir compte de l’autonomie requise par les gestionnaires de
ressources et afin d’éviter les blocages, nous proposons d’organiser la
manipulation des ressources durant l’exécution des processus distribués
en trois phases (Figure 7-4) :
Phase 1
Réservation : le mécanisme d’allocation des ressources demande à
chaque gestionnaire de ressource de réserver les ressources
nécessaires. Lorsque la ressource est réservée, le message OK est
envoyé au mécanisme d’allocation de ressources. Lorsque toutes les
ressources nécessaires ont répondu OK la phase 2 commence. Dès
Mayyad JABER 129
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
qu’un gestionnaire répond négativement ou lorsque le délai d’attente
maximum est dépassé, le processus est interrompu et les pré-
réservations doivent être libérées.
Figure 7-4 Transition d’état d’une ressource dans un processus commun
Phase 2 :
Traitement des exceptions : durant les périodes d’attentes passées
avant le début de l’exécution d’un processus, les demandes
d’exception (en raison des changements de contexte) sont acceptées
et des instructions release_R sont émises en cas de besoin.
Exécution : si toutes les ressources nécessaires sont réservées et
sont dans un état "Prêt", les gestionnaires de ressources autorisent le
lancement du processus distribué. Lorsqu’un processus est terminé,
les gestionnaires des ressources renvoient le message "Fait" au
mécanisme d’allocation de ressources.
Mayyad JABER 130
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Phase 3
Libération : le mécanisme d’allocation des ressources demande aux
gestionnaires des ressources (non consommées) engagées de libérer ces
ressources qui deviennent de nouveau disponibles et prêtes à être
impliquées dans de nouveaux processus.
L’organisation du mode de fonctionnement en trois phases
offre une solution pour la gestion de demandes concurrentes de
ressources provoquant des interblocages grâce à la prise en compte des
délais d’attente maximum. Néanmoins, des exceptions peuvent survenir
durant la phase d’exécution à cause d’événements imprévus. Ceci
nécessite une facilité permettant la restauration des états initiaux de
ressources afin d’éviter un résultat incohérent.
7.2.4 Retour en arrière
À ce stade, le mécanisme d’allocation des ressources n’est pas en
mesure de traiter le problème des processus préemptifs, problème qui
pourraient se poser dans le domaine de la chaîne logistique. Cela est
réalisé en fournissant un mécanisme de retour en arrière pour le
traitement des exceptions provoquées par l’évolution du contexte. Ce
retour en arrière est lancé dans le cas où une procédure d’urgence doit
être exécutée malgré le fait que les ressources nécessaires soient pré-
engagées dans un processus en cours d’exécution. Une possibilité est le
cas où le système doit forcer la suspension d’un processus en cours
d’exécution en raison d’un échec dans le système. Pour cela nous
proposons d’ajouter un mécanisme de retour en arrière dans la "phase 2"
comme suit :
Retour en arrière (restauration d’état) : au cours de l’exécution,
le gestionnaire de ressources reçoit un ordre Rollback de la part
du mécanisme d’allocation des ressources afin de suspendre le
processus en cours et de remettre la ressource dans son état initial.
La Figure 7-5 montre le rôle du mécanisme de retour en arrière dans
les changements d’état des ressources.
Mayyad JABER 131
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Lorsque la ressource notifie le gestionnaire de ressources associé de la fin
de l’exécution avec un message "Terminé", le gestionnaire de ressource
répond par un des deux messages :
"Relâche" dans le cas où le processus commun se termine avec
succès. Dans ce cas, les modifications apportées sur la ressource
deviennent définitives et la ressource entre de nouveau dans un état
"Disponible" (si elle n’a pas été consommée).
"Retour en arrière" dans le cas où le processus commun se termine
en échec. Dans ce cas, les modifications apportées sur la ressource
seront annulées et la ressource restaure l’état initial et entre dans un
état "Disponible".
Figure 7-5 Retour en arrière
L’utilisation de trois phases avec le mécanisme de retour en
arrière pour l’exécution du processus distribué offre une garantie pour
l’exécution cohérente du processus commun au niveau "Ressources".
Avec le mécanisme de gestion de ressources proposé, le processus
d’allocation et d’accès aux ressources distribuées devient stable en
offrant les moyens nécessaires pour répondre aux exceptions potentielles
dans le système. En revanche, au niveau processus, il manque toujours
des facilités pour garantir l’exécution du processus commun dans un
milieu peu stable comme le milieu du B2B. Nous allons utiliser les
Mayyad JABER 132
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
notions proposées pour la gestion de ressources distribuées afin de
construire un processus commun transactionnel. Nous allons intégrer un
système de gestion de transaction distribuée dans notre architecture
cadre. Ce système est dédié à la résolution des problèmes issus de
l’exécution du processus commun organisant un couplage lâche entre
sous processus.
7.3 Gestion de transaction
Afin de supporter une gestion automatisée pour le processus commun,
nous avons proposé d’intégrer une organisation sous forme de Workflow
distribué. Dans ce cas, les principaux problèmes sont dus à l’exécution
distribuée du Workflow global comprenant à la fois des liaisons directes
avec des processus publics et des liaisons indirectes avec des processus
privés. Cette exécution distribuée nécessite de définir comment restaurer
les états initiaux des systèmes engagés dans le processus commun en cas
d’interruption de l’exécution. Cela impose de mettre en place des outils
tolérants aux pannes pour le traitement des exceptions potentiel les dans
un système de couplage lâche basé sur la composition de services Web
distribués. C’est pourquoi nous proposons d’ajouter les facilités des
systèmes de gestion de transactions à notre architecture [Jaber et al.,
2006c].
Les systèmes traditionnels de gestion de transactions offrent les
propriétés ACID (Atomicity, Consistency, Isolation, Durability) et 2PC
(two Phase Commitment) (sections 3.5, 4.5.2). La rigidité de ces
systèmes empêche leur utilisation pour supporter le processus commun.
Ces limites ont été prises par des protocoles dédiés pour le domaine de
B2B tel que le BTP, WS-Coordination, et WS-Transaction (section
4.5.3). Le problème avec ces protocoles est qu’il s’agit du codage
intégré de la logique métier dans les protocoles de transactions. Cela
impose un couplage fort entre les services métiers et les composants
dédiés pour la gestion de transaction. En plus, les informations
échangées entre les composants transactionnels ne peuvent pas être
propagées vers les services métiers. Ces informations sont de grosse
utilité quand il s’agit des informations d’aspect métier comme celles qui
sont liées aux disponibilités de ressources par exemples. A cet effet,
nous nous avons inspiré de ces techniques pour bâtire un système de
Mayyad JABER 133
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
gestion de transactions distribuées dans notre architecture distribuée. Le
but est de proposer un modèle de processus métier commun
transactionnel distribué avec les entités de gestion de transaction
intégrées dans la structure du processus commun. Ce système répond
aux exigences du processus commun qui n’est pas forcement prédéfini et
en conséquence peut avoir plusieurs configuration selon le contexte
métier.
7.3.1 Processus métier commun transactionnel
Dans cette partie, nous allons détailler notre approche pour la gestion du
processus commun distribué transactionnel composé en s’appuyant sur
l’architecture cadre. Dans ce cadre, chaque entreprise participante est
représentée comme un nœud. L’ensemble des nœuds et les moyens de
communication les reliant formeront le système d’information distribué
pour la gestion de la chaîne logistique. Les nœuds contiennent les
différents services offerts par les systèmes d’informations patrimoniaux,
représentés sous forme de services Web. Afin de réaliser un processus
commun interentreprises, plusieurs services issus d’au moins deux
nœuds seront regroupés, formant le processus commun (Figure 7-6).
Figure 7-6 Composition du processus commun transactionnel
Entreprise B Entreprise A
Processus commun
Echange intra-entreprise
Echange interentreprises
Flux de Control
Processus métier privé
Processus métier public
Service Web
Gestionnaire de transaction
Légendes
Niveau de
services
Niveau de gestionnaires
de transaction
Niveau de processus
métier
Mayyad JABER 134
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Pour supporter la cohérence et la durabilité du processus
commun, les processus impliqués dans la transaction doivent être
surveillés afin de coordonner les actions des différents sous-processus
engagés dans le processus commun. L’idée essentielle du système de
gestion que nous proposons est de fournir un mécanisme pour éviter de
procéder à l’exécution d’un processus commun avant qu’on garantisse la
possibilité de l’accomplir correctement. Ceci impose d’exécuter une
phase de préparation pour tous les sous-processus participant avant
d’entamer la phase d’exécution.
Le gestionnaire de transaction global (celui qui initie la
transaction) peut contrôler l’exécution des différents sous processus
couplés à des gestionnaires de transaction locaux. La gestion de
transactions distribuées consiste ainsi à contrôler l’exécution du
processus commun dynamiquement afin de garantir qu’on atteigne un
résultat cohérent. En cas d’exception, toutes les modifications doivent
être annulées et le système doit être remis à l’état initial. A cet effet, le
système proposé doit fournir une facilité de « retour en arrière » en cas
d’échec après l’initialisation de la phase d’exécution. Ainsi, le
gestionnaire de transaction joue un rôle de garant pour le service auquel
il est associé. Cela signifie qu’il doit garantir que tous les autres services
engagés dans la transaction sont prêts à s’exécuter.
7.3.2 Nesting (emboîtement) et notion de veto-Set
Dans un contexte de collaboration interentreprises tel que celui de la
chaîne logistique, le processus commun est initié par un partenaire pour
atteindre un objectif métier commun avec les entreprises partenaires.
Chaque participant au processus commun expose ses services par le
biais de services Web. Dans certains cas, l’exécution d’un service Web
impliqué dans un processus commun implique l’invocation d’autres
services Web à un niveau secondaire. Dans l’exemple de la section 7.2
(Figure 7-1), c’est le cas où le fabricant fait un appel aux fournisseurs de
matières premières pour exécuter un processus d’approvisionnement en
invoquant les services adéquats. Ce processus d’approvisionnement
représente un sous-processus secondaire pour le processus commun.
L’imbrication de sous-processus dans le processus commun conduit à
Mayyad JABER 135
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
organiser les composants du système de transaction distribuée dans une
hiérarchie incluant plusieurs niveaux selon le rôle de chaque composant.
Par ailleurs, dans le processus commun, nous constatons que
certains sous processus sont obligatoires tandis que d’autres ne le sont
pas. Dans l’exemple de la section 7.2, le sous-processus réalisé par le
fabricant est un sous-processus impératif (le traitement de commande ne
peut pas aboutir sans l’engagement du fabricant), alors que l’état du
sous-processus associé au transporteur est défini par le grossiste en
fonction de ses besoins. Les sous-processus obligatoires constituent un
ensemble de sous processus que nous appelons "veto-set". Le veto-set
représente l’idée que le processus commun ne peut pas être exécuté sans
la confirmation de tous les sous-processus figurant dans ce veto-set
[Jaber et al., 2006c].
En prenant en compte ces contraintes (transactions imbriquées
et veto-set), nous présentons dans les paragraphes suivants un système
hiérarchisé pour la gestion de transactions distribuées.
7.3.3 Hiérarchie des transactions Distribuées
Le système de gestion de transactions est organisé d’une manière
distribuée. Plusieurs rôles sont consacrés aux différents composants de
la transaction globale en fonction de charges associées. Généralement,
nous distinguons trois rôles différents pour les gestionnaires de
transactions :
Racine : c’est le gestionnaire de transaction lié à l’initiateur du
processus commun. Il est chargé de contrôler le processus global.
Dans notre exemple, il s’agit du gestionnaire de transaction
associé au distributeur et contrôle un processus de traitement de
commande.
Inférieur : dans ce cas, le service associé ne possède pas de sous
processus. Le gestionnaire de transaction lié à ce service est un
inférieur "pur". Il s’agit du transporteur dans notre exemple.
Supérieur/inférieur : c’est le gestionnaire de transaction d’un
service lié avec un ou plusieurs sous-processus. Il joue le rôle
d’un inférieur vis-à-vis du gestionnaire de transaction racine, mais
il joue aussi le rôle d’un supérieur (racine secondaire) par rapport
Mayyad JABER 136
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
aux gestionnaires de transaction associés aux sous-processus.
Dans notre exemple, quand le fabricant décide d’approvisionner
des matières premières afin de satisfaire la commande, il invoque
les services proposés par les fournisseurs. Le gestionnaire de
transaction délégué par le fabricant joue le rôle d’un inférieur vis-
à-vis du distributeur et le rôle d’un supérieur (racine secondaire)
par rapport aux fournisseurs de matières premières.
La Figure 7-7 représente une hiérarchie des entités métiers
correspondant à l’exemple de la section 7.2.
Figure 7-7 Exemple d’une hiérarchie de transaction distribuée
Ainsi un processus transactionnel sera initialisé par un service
Web pour réaliser un objectif métier d’une entreprise. On appellera ce
service Web "initiateur". Ce service est associé à un gestionnaire de
transaction pour la coordination du processus global. Le gestionnaire de
transaction de l’initiateur joue le rôle de gestionnaire de transaction
racine. Par contre, les gestionnaires de transactions associés aux autres
services sont des inférieurs ou bien des inférieurs/supérieurs par rapport
à ce gestionnaire racine (Figure 7-8). Une liste de tous les services
participants sera fournie par le service Web initiateur au gestionnaire de
transaction racine. Après cette étape, l’initiateur entre dans un état
d’attente pour la réponse du gestionnaire de transaction racine avant de
Transporteur
Inférieur
Fabricant
Supérieur/Inférieur
Fournisseur 2
Inférieur
Fournisseur 1
Inférieur
Distributeur
Racine
Mayyad JABER 137
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
procéder à la phase d’exécution. Dans le paragraphe suivant, nous allons
détailler les différentes phases d’exécution d’une transaction distribuée.
Figure 7-8 Hiérarchie de gestionnaires de transactions distribuées
7.3.4 Différentes phases d’exécution d’une transaction distribuée
Le suivi de la transaction distribuée implique de contrôler l’exécution du
processus commun afin de garantir que l’objectif global a été atteint ou
bien que l’état initial du système a été restauré. Le rôle de chaque
gestionnaire de transaction dans un processus commun est de garantir
que tous les acteurs impliqués (les services Web distribués) sont
capables de s’acquitter de la tâche associée avant de débuter l’exécution.
En outre, les gestionnaires de transactions supervisent les résultats
partiels au cours de l’exécution. Ils ordonnent à tous les participants
d’exécuter un processus de restauration (retour en arrière) quand une
Mayyad JABER 138
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
erreur survient. Pour chaque gestionnaire de transaction, le processus est
organisé en trois phases :
Phase 1 : Préparation : le gestionnaire de transaction racine
demande à chaque gestionnaire de transaction de niveau inférieur
d’agir pour verrouiller les ressources requises. Si un gestionnaire de
transaction participant agit comme un supérieur/inférieur (c’est-à-
dire q’il gère à son tour des sous gestionnaires), il doit propager
cette phase de préparation sur les différents gestionnaires de
transactions qu’il contrôle. Lorsque la ressource est verrouillée, le
message OK est envoyé au gestionnaire de transaction racine. Si un
inférieur membre du veto-set renvoie échec ou si un trigger est
activé avant que tous les inférieurs aient répondu, la transaction est
annulée (avortée) et un message d’annulation est envoyé aux sous
gestionnaires de transaction afin de libérer leurs ressources.
Phase 2 : Confirmation (commit) : si toutes les ressources sont
verrouillées, le gestionnaire de transaction racine demande aux
inférieurs de procéder à l’exécution et entre dans un état d’attente
pour des réponses "accompli". Si un gestionnaire gère aussi des
sous-gestionnaires, il demande à son tour aux sous-gestionnaires de
procéder à l’exécution. Les gestionnaires de ressources
accomplissent l’opération et envoient des messages "accompli" aux
gestionnaires de niveau supérieur. Les messages "accompli" seront
ensuite propagés au gestionnaire de transaction racine. Si un
gestionnaire figurant dans le veto-set répond avec un message "non
accompli", ou ne répond pas dans un délai prédéfini, le gestionnaire
racine de transaction demande aux autres gestionnaires d’annuler la
transaction qui se termine avec un échec.
Phase 3: finalisation ou retour en arrière (rollback) : si tous les
gestionnaires répondent avec "accompli", le gestionnaire de
transaction racine finalise la transaction avec succès. Si un
gestionnaire membre du veto-set répond avec "insuffisance", ou ne
répond pas de tout (délai dépassé) (time over), le gestionnaire racine
demande à tous les autres gestionnaires d’exécuter un processus de
retour en arrière et la transaction se termine par un échec. Si les
Mayyad JABER 139
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
autres gestionnaires ne reçoivent pas de messages de finalisation ou
bien de retour en arrière de la part du gestionnaire racine après une
période prédéfinie, chaque gestionnaire procède automatiquement à
un processus de retour en arrière.
Afin de clarifier le mode de fonctionnement pour les
gestionnaires de transactions et leur transitions d’états durant
l’exécution des trois phases, nous présenterons un automate générique
pour les différents gestionnaires de transaction distribuées. A cet effet,
nous présentons les notations que nous utiliserons pour représenter les
automates des différents gestionnaires de transactions.
7.3.5 Notations pour les automates de gestionnaires de transactions
Afin de normaliser la représentation des automates de gestionnaires de
transactions, nous allons décrire ces automates par le biais de
diagrammes de transition d’état. Dans ces diagrammes, nous allons
présenter les transitions d’état pour les gestionnaires de transactions de
chaque niveau avec les messages échangés (entrant/sortant) entre les
différents niveaux de la hiérarchie du système de gestion de transactions
distribuées. A cet effet, nous aurons besoin des éléments suivants :
Etat : il s’agit de l’élément de base dans les diagrammes de
transition d’état. L’organisation de l’architecture que nous
proposons (avec la possibilité d’imbrication entre les gestionnaires
de différents niveaux) impose de garder en mémoire l’état du
gestionnaire de transaction (ou de la sous-transaction) avec une
indication du gestionnaire concerné. Dans un souci de lisibilité,
nous rappelons le nom de gestionnaire pour chaque état dans les
diagrammes.
Evénement entrant : c’est l’événement qui provoque la transition
d’état pour un gestionnaire de transaction. Dans notre architecture
orientée services, il s’agit plus précisément d’un message qui sera
reçu par un gestionnaire de transaction en provenance d’un autre
gestionnaire de transaction (d’un niveau supérieur ou inférieur).
Mayyad JABER 140
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Evénement sortant : il permettra l’activation d’un autre
gestionnaire grâce à un message produit en réaction à un événement
entrant pour :
1. Ordonner à un gestionnaire de niveau inférieur d’exécuter une
tâche (préparation, validation, annulation, …)
2. Informer un gestionnaire de niveau supérieur de l’exécution
d’une tâche.
Evénement interne : ce type d’événement sera utilisé dans les
diagrammes proposés pour représenter les événements de
dépassement de temps qui peuvent se produire lorsque un
gestionnaire demeure dans un état d’attente.
Décision : nous utilisons l’élément décision pour vérifier que tous
les messages ont été envoyés/reçus à la fin d’une phase par
exemple.
Flux de contrôle : pour montrer les directions de transition d’état
pour chaque gestionnaire de transaction.
Flux de données : pour montrer les directions des messages
échangés entre les différents gestionnaires dans un seul diagramme.
Phase : afin de réduire la complexité et améliorer la lisibilité des
diagrammes, nous allons représenter les différentes phases
d’exécution de transaction distribuée (section 7.3.4) sous forme
d’une macro-procédure simplifiée.
Partant de ces éléments, nous avons constaté que nous pouvons
utiliser le Langage de Description et de Spécification (LDS) [ITU-T,
1999] pour élaborer les diagrammes proposés. Ce langage est dédié
initialement à fournir des spécifications et des descriptions univoques
pour le comportement de système de télécommunication. Nous avons
adapté les symboles de ce langage pour traiter les aspects liés à
l’organisation de la structure de système de transactions distribuées
proposé dans la section 7.3.3.
Afin de montrer les états de transaction et des sous-transactions
ainsi que les liens entre les différents gestionnaires de transaction dans
chaque diagramme, nous avons ajouté (par rapport aux états de LDS) le
nom de gestionnaire sur les états et l’indication du flux de message
grâce à des flèches pointillées pour montrer les messages échangés entre
les gestionnaires de transaction. En outre, les éventements dans LDS
seront utilisés pour représenter les messages échangés entre les
Mayyad JABER 141
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
gestionnaires de transactions de différents niveaux. Le Tableau 7-1
montre les éléments venant de LDS que nous avons utilisé avec les
adaptations que nous avons réalisés.
Symbole LDS Symbole adopté
État
Nom du gestionniare
Etat du gestionnaire
Entrée
Entrée
Entrée
interne
Entrée
interne
Sortie
Sortie
Décision
Décision
Flux de contrôle
Flux de contrôle
N/A Flux de données
Procédure
Phase
Tableau 7-1 Symboles adoptés pour les diagrammes des gestionnaires de
transactions
7.3.6 Automate générique pour les algorithmes de gestionnaires de
transactions
Le mode de fonctionnement du système dédié pour la gestion de
transactions distribuées peut être représenté par un algorithme générique
Mayyad JABER 142
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
qui illustre les différents rôles de gestionnaires de transactions (Figure
7-9). Le gestionnaire de transaction racine envoie des ordres aux
différents gestionnaires de niveau inférieur enregistrés pour l’exécution
de la transaction. Ensuite, le gestionnaire racine entre dans en état
d’attente pour leur réponses (Ok / non Ok (échec en général)) afin de
décider de l’étape suivante. Dans chacune des phases présentées (section
7.3.4) nous avons traité le problème d’interblocages potentiels en
ajoutant des triggers pour chaque gestionnaire de transaction (Racine,
Supérieur/Inférieur, Inférieur). Ces triggers permettent de donner un
niveau d’indépendance à chaque sous-processus et aux gestionnaires de
ressources en cas de dépassement de temps prédéfini. Ils permettent aux
gestionnaires concernés de relâcher les ressources dans la phase 2 ou
bien de procéder à une phase de retour en arrière dans la phase 3. Ce
faisant, les gestionnaires de transactions et les gestionnaires de
ressources gardent l’indépendance nécessaire pour éviter les
interblocages issus d’exceptions durant l’exécution du processus
commun.
Les modifications réalisées sur les ressources ne seront
définitives que dans le cas où la transaction se termine avec succès,
sinon, la racine lance un processus de retour en arrière au cours de la
phase 3 qui sera propagé jusqu’aux gestionnaires de ressources
participants.
Mayyad JABER 143
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 7-9 Automate générique pour les gestionnaires de transactions
En se basant sur ce diagramme, nous allons détailler dans le
reste de ce chapitre les différents rôles de gestionnaires de transactions
distribués avec leurs diagrammes de transition d’états.
7.3.7 Transition d’états du gestionnaire de transaction "racine"
Le gestionnaire de transaction racine commence par préparer les
gestionnaires de transactions liés directement avec lui. Ensuite il entre
dans un état d’attente de leur réponses. Si un trigger de dépassement de
temps est déclenché avant que toutes les réponses soient reçues, ou si un
message "échec" d’un gestionnaire de transaction participant est reçu, la
transaction sera annulée. Dans les autres cas, une phase de "commit"
Mayyad JABER 144
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
commence et le Gestionnaire de transaction racine entre dans un état
d’attente pour les résultats. Si le message "Accompli" est reçu dans le
délai prédéterminé, la transaction se termine avec succès, sinon, une
phase de retour en arrière commence pour « défaire » les actions
accomplies (Figure 7-10).
En se basant sur l’automate présenté dans la Figure 7-10, nous
allons développer un diagramme pour décrire le mode de
fonctionnement d’un gestionnaire de transaction racine. Pour simplifier
l’explication du diagramme (Figure 7-11), nous allons présenter les
différents états et phases possibles pour un gestionnaire de transaction
racine durant l’exécution d’une transaction distribuée :
Phase d’initialisation
Après la création de gestionnaire de transaction racine à la
demande du service initiateur, le gestionnaire de transaction racine entre
dans un état de "Attente_Inférieur_ID".
Etat "Attente enregistrement des inférieurs" (Atn_Inférieur_Id)
On sort de cet état grâce à deux sorties :
Un trigger "Délai_dépassé" est déclenché avant que tous les
gestionnaires de niveau inférieur soient enregistrés. Dans ce
cas, le service initiateur sera consulté pour déterminer si la
liste des gestionnaires enregistrés est suffisante. Le
gestionnaire racine envoie la "Liste_Enregistré" au service
initiateur et entre ensuite dans un état d’attente de réponse
(Atn_WS_Réponse). Par exemple, on considère une
demande d’achat qui intègre un service de transport. Dans
le cas où le gestionnaire lié au service de transport n’a pas
pu s’enregistrer à cause d’un échec du réseau ou d’une
panne concernant le service lui-même, l’initiateur peut
décider soit de solliciter un autre transporteur pour assurer
ce processus de transport (ce qui permet de poursuivre la
transaction) soit d’abandonner la transaction.
Mayyad JABER 145
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 7-10 Transitions d’état pour un gestionnaire de transaction racine
Mayyad JABER 146
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Une demande d’enregistrement "Enregistre Inférieur_ID"
des gestionnaires de niveau inférieur pour être enregistrés
comme des participants dans la transaction globale. Le
gestionnaire de transaction racine leur envoie aussitôt un
message de confirmation "Enregistré". Lorsque tous les
services concernés dans le processus commun sont
enregistrés, le gestionnaire de transaction racine entame la
"Phase de Préparation".
Etat "Attente_serviceWeb_Réponse"
Dans cet état, le gestionnaire de transaction racine attend la
décision du service Web initiateur sur la liste des gestionnaires de
niveau inférieur enregistrés. On sort de cet état grâce à trois sorties :
Un trigger "Délai_dépassé" se produit. Le gestionnaire
racine entame la phase "Avorte_Transaction".
Le gestionnaire racine reçoit un message "Avorte" de la
part du service Web initiateur. Ce gestionnaire racine
entame la phase "Avorte_Transaction".
Le gestionnaire racine reçoit un message "Continue" de la
parte du service Web initiateur. Ce gestionnaire entame la
"phase de préparation".
Phase de préparation
Dans cette phase, le gestionnaire de transaction racine organise
avec tous les gestionnaires inférieurs enregistrés l’exécution de
transaction globale. Il envoie des messages de préparation
"Prépare_Inférieur_ID" pour tous les gestionnaires inférieurs enregistrés
dans l’étape précédente. Puis, il attend que les gestionnaires inférieurs
soient prêts (Atn_Infs_Prêt).
Etat "Attente Inférieurs prêt" (Atn_Infs_Prêt)
Le gestionnaire de transaction racine reçoit les réponses des
gestionnaires inférieurs aux messages "Prépare_Inférieur_ID". On sort
de cet état grâce à trois sorties :
Mayyad JABER 147
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Une réponse négative ("Insuffisance_Inférieur_ID")
provient d’un gestionnaire inférieur qui fait partie du
groupe de veto. Le gestionnaire racine envoie un message
"Insuffisance" au service initiateur et ensuite entame la
phase "Avorte Transaction".
Un trigger "Délai_dépassé" se produit avant la réception de
toutes les réponses des gestionnaires inférieurs. Dans ce
cas, le service Web initiateur sera consulté pour déterminer
si la liste des services préparés est suffisante pour valider
(commit) la transaction. Pour ce faire, une liste des
gestionnaires inférieurs prêts ("Liste_prêts") est envoyée au
service initiateur. Ensuite, le gestionnaire de transaction
racine entre dans l’état d’attente de validation
(Atn_Valide).
Une réponse positive (Prêt Inférieur_Id_) est reçue. Dans ce
cas, on enregistre cette réponse. Si tous les gestionnaires
inférieurs ont répondu (positivement ou négativement), une
liste des gestionnaires inférieurs prêts ("Liste_prêts") est
envoyée au service initiateur. Ensuite, le gestionnaire de
transaction racine entre dans l’état d’attente de validation
(Atn_Valide).
Phase avorte transaction
Dans cette phase, le gestionnaire de transaction racine ordonne
à tous les gestionnaires inférieurs enregistrés d’avorter la transaction en
envoyant des messages "Avorte_Inférieur_ID" à tous les gestionnaires
inférieurs enregistrés. A la fin de cette phase, le gestionnaire racine
entre dans l’état "Terminé".
Etat "attente de validation (Atn_Valide)
Dans cet état, le gestionnaire de transaction racine attend la
décision du service initiateur sur la liste des gestionnaires inférieurs
prêts. On sort de cet état grâce à trois sorties :
Un trigger "Délai_dépassé" se produit. Le gestionnaire
racine entame la phase "Avorte_Transaction".
Mayyad JABER 148
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le gestionnaire racine reçoit un message "Avorte" de la
part du service initiateur. Ce gestionnaire entame la phase
"Avorte_Transaction".
Le gestionnaire racine reçoit un message "Valide" de la
parte du service initiateur. Le gestionnaire racine entame la
"Phase de Validation".
Phase de Validation
Dans cette phase, le gestionnaire de transaction racine active
tous les gestionnaires inférieurs prêts afin de valider l’exécution
(commit) de la transaction globale. Il envoie des messages
"Valide_Inférieur_ID" à tous les gestionnaires inférieurs prêts. Ensuite,
il entre dans l’état d’Attente d’accomplissement de transaction
(Atn_Accompli).
Etat attente d’accomplissement de transaction (Atn_Accompli)
Dans cet état, le gestionnaire de transaction racine reçoit les
réponses des gestionnaires inférieurs aux messages
"Valide_Inférieur_ID". On sort de cet état grâce à trois sorties :
Une réponse négative "Echec_Inférieur_ID" d’un
gestionnaire inférieur. Le gestionnaire racine envoie un
message "Echec" au service initiateur et entame ensuite la
phase de "Retour en Arrière".
Un trigger "Délai_dépassé" se produit avant la réception de
toutes les réponses des gestionnaires inférieurs. Dans ce
cas, le gestionnaire racine envoie un message "Echec" au
service initiateur et entame la phase de "Retour en Arrière".
Le gestionnaire racine reçoit une réponse positive
(Accompli Inférieur_Id) et l’enregistre. Quand les réponses
positives de tous les gestionnaires inférieurs sont reçues, le
gestionnaire racine entame la "Phase de Finalisation".
Phase de retour en arrière
Dans cette phase, le gestionnaire de transaction racine ordonne
à tous les gestionnaires inférieurs de restaurer leur état initial. Il envoie
Mayyad JABER 149
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
des messages de retour en arrière (R_en_Ar) à tous les gestionnaires
inférieurs qui ont accompli leur tâches puis, il entre dans l’état
"Terminé".
Phase de finalisation
Dans cette phase, le gestionnaire de transaction racine ordonne
à tous les gestionnaires inférieurs de terminer la transaction. Il envoie
des messages "Termine_Inférieur_ID" à tous les gestionnaires inférieurs.
Ensuite, il entre dans l’état "Terminé". Dans ce cas, les modifications
apportées sur les ressources seront définitives et la transaction se
termine avec succès.
Mayyad JABER 150
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 151
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 7-11 Gestionnaire de transaction racine
Mayyad JABER 152
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
7.3.8 Rôle du gestionnaire de transaction "inférieur"
Après avoir reçu un message de l’initiateur lui demandant d’initialiser
un processus transactionnel, chaque service participant à un processus
commun transactionnel délègue un gestionnaire de transaction
"Inférieur" pour coordonner ses activités dans la transaction globale.
Après la création de gestionnaire de transaction inférieur (suite à la
demande de l’initiateur), le gestionnaire de transaction inférieur envoie
un message d’enregistrement "Enregistre Inférieur_ID" au gestionnaire
de niveau supérieur (par exemple un gestionnaire racine) et entre ensuite
dans un état de d’attente d’enregistrement par la racine (Atn_Enregistré)
(Figure 7-12).
Etat d’attente d’enregistrement (Atn_Enregistré)
Dans cet état, le gestionnaire de transaction inférieur attend un
message de confirmation du gestionnaire racine; on en sort sur deux
événements :
Un trigger "Délai_dépassé" est déclenché avant la réception
du message "Enregistré" de venant du gestionnaire
supérieur. Dans ce cas, le gestionnaire inférieur entre dans
l’état "Terminé" et la sous-transaction contrôlée par ce
gestionnaire inférieur se termine en échec.
Le message "Enregistré" venant de gestionnaire supérieur
est reçu. Dans ce cas, ce gestionnaire inférieur entre dans
l’état d’attente de préparation.
Etat d’ttent de préparation (Atn_Prépare)
Dans cet état, le gestionnaire de transaction inférieur attend un
message de préparation "Prépare Inférieur_ID" de la part de gestionnaire
de transaction de niveau supérieur. On sort de cet état grâce à trois
sorties :
Un trigger "Délai_dépassé" est déclenché avant la réception
du message "Prépare Inférieur_ID" venant du gestionnaire
de niveau supérieur. Dans ce cas, le gestionnaire inférieur
Mayyad JABER 153
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
entre dans l’état "Terminé" et la sous-transaction contrôlée
par gestionnaire se termine en échec.
Le message "Avorte Inférieur_ID" est reçu du gestionnaire
de niveau supérieur. Dans ce cas, ce gestionnaire inférieur
entre dans l’état "Terminé" et la sous-transaction contrôlée
par ce gestionnaire inférieur se termine avec échec.
Le message "Prépare Inférieur_ID" venant du gestionnaire
de niveau supérieur est reçu. Dans ce cas, ce gestionnaire
inférieur entame la phase de préparation.
Phase de préparation
Dans cette phase, le gestionnaire inférieur ordonne à tous les
gestionnaires de ressources (GR) associés de préparer leurs ressources
pour traiter la transaction en envoyant des messages "Prépare GR_ID".
Cela permet aux gestionnaires de ressources de réserver les ressources
nécessaires pour traiter la transaction. A la fin de cette phase, le
gestionnaire inférieur entre dans l’état d’attente des réponses des
gestionnaires de ressources (Atn_GR_Prêt).
Etat d’attente des réponses des gestionnaires de ressources
(Atn_GR_Prêt)
Dans cet état, le gestionnaire de transaction inférieur attend un
message de confirmation (Prêt GR_ID) de la part des gestionnaires de
ressources associés. On sort de cet état grâce à trois sorties :
Un trigger "Délai_dépassé" est déclenché avant la réception
de toutes les réponses ("Prêt GR_ID"/"Insuffisance
GR_ID") des gestionnaires de ressources associés. Dans ce
cas, ce gestionnaire inférieur entame la phase "Avorte
Transaction" et entre dans l’état "Terminé". La sous-
transaction contrôlée par ce gestionnaire inférieur se
termine en échec.
Une réponse négative (message Insuffisance GR_ID) est
reçue de la part d’un gestionnaire de ressource. Dans ce cas,
le gestionnaire inférieur entame la phase "Avorte
Transaction" et entre dans l’état "Terminé". La sous-
Mayyad JABER 154
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
transaction contrôlée par ce gestionnaire inférieur se
termine en échec.
Une réponse positive (Prêt GR_Id) est reçue : dans ce cas la
réponse est enregistrée. Lorsque tous les gestionnaires de
ressources ont répondu positivement, le gestionnaire
inférieur envoie un message "Prêt Inférieur_ID" au
gestionnaire de niveau supérieur et entre dans l’état
d’attente de validation.
Phase Avorte Transaction
Dans cette phase, le gestionnaire inférieur ordonne à tous les
gestionnaires de ressources associés d’avorter la transaction. Il envoie
des messages "Avorte GR_ID" à tous les gestionnaires de ressource
associés. Cela permet aux gestionnaires de ressources de relâcher les
ressources réservées pendant la phase de préparation. A la fin de cette
phase, le gestionnaire inférieur entre dans l’état "Terminé". La sous-
transaction contrôlée par ce gestionnaire termine en échec.
Etat d’attente de validation (Atn_Valide)
Dans cet état, le gestionnaire de transaction inférieur attend un message
de validation ou d’avortement de la part du gestionnaire de transaction
de niveau supérieur. On sort de cet état grâce à trois sorties :
Un Trigger "Délai_dépassé" est déclenché avant la
réception de la réponse du gestionnaire de niveau supérieur.
Dans ce cas, le gestionnaire inférieur entame la phase
"Avorte Transaction" puis entre dans l’état "Terminé". La
sous-transaction contrôlée par ce gestionnaire se termine en
échec.
Le message"Avorte Inférieur_ID" est envoyé par le
gestionnaire de niveau supérieur. Dans ce cas, le
gestionnaire inférieur entame la phase "Avorte Transaction"
et entre dans l’état "Terminé". La sous-transaction
contrôlée par ce gestionnaire se termine en échec.
Le message"Valide Inférieur_ID" est envoyé par le
gestionnaire de transaction de niveau supérieur. Dans ce
cas, ce gestionnaire entame la "Phase de Validation".
Mayyad JABER 155
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Phase de validation
Dans cette phase, le gestionnaire inférieur active tous les
gestionnaires de ressources associés afin de valider (commit) la
transaction. Il envoie des messages "Valide GR_ID" à tous les
gestionnaires de ressource associés. Cela permet aux gestionnaires
de ressources d’effectuer les changements nécessaires au niveau
des ressources réservées pendant la phase de préparations. A la fin
de cette phase, ce gestionnaire entre dans l’état d’attente
d’accomplissement de cette tâche par les gestionnaires de
ressources.
L’état d’attente de validation par les gestionnaires de ressources
(Atn_Accompli)
Dans cet état, le gestionnaire de transaction inférieur attend les
messages de confirmation "Accompli GR_ID" de la part des
gestionnaires de ressources associés. On sort de cet état grâce à trois
sorties :
Un trigger "Délai_dépassé" est déclenché avant la réception
de toutes les réponses ("Accompli GR_ID"/"Echec
GR_ID") des gestionnaires de ressources associés. Dans ce
cas, ce gestionnaire de transaction envoie un message
"Echec Inférieur_ID" au gestionnaire de transaction de
niveau supérieur et entame la "Phase de Retour en Arrière".
A la fin de cette phase, il entre dans l’état "Terminé". La
sous-transaction contrôlée par ce gestionnaire se termine en
échec.
Le message "Echec GR_ID" de la part d’un gestionnaire de
ressource est reçu. Dans ce cas, le gestionnaire de
transaction inférieur envoie un message "Echec
Inférieur_ID" au gestionnaire de transaction de niveau
supérieur et entame la "Phase de Retour en Arrière". A la
fin de cette phase, il entre dans l’état "Terminé". La sous-
transaction contrôlée par ce gestionnaire se termine en
échec.
Mayyad JABER 156
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Tous les gestionnaires de ressources ont répondu avec un
message "Accompli GR_ID". Dans ce cas, le gestionnaire
de transaction inférieur envoie un message "Accompli
Inférieur_ID" au gestionnaire de niveau supérieur et entre
dans l’état "Attente_Termine".
Etat d’attente de terminaison venant de gestionnaire de niveau
supérieur (Atn_Termine)
Dans cet état, le gestionnaire de transaction inférieur attend la
décision de gestionnaire de niveau supérieur sur la continuité de
transaction. On sort de cet état grâce à trois sorties :
Un trigger "Délai_dépassé" se produit. Ce gestionnaire
entame la "Phase de Retour en Arrière".
Le gestionnaire inférieur reçoit un message
"Retour_en_Arrière Inférieur_ID" de la part de gestionnaire
de niveau supérieur. Ce gestionnaire entame la "Phase de
Retour en Arrière".
Le gestionnaire inférieur reçoit un message "Termine
Inférieur_ID" de la part du gestionnaire de niveau
supérieur. Ce gestionnaire inférieur entame la "Phase de
Finalisation".
Phase de Retour en Arrière
Dans cette phase, le gestionnaire inférieur ordonne le retour en
arrière à tous les gestionnaires de ressources associés afin d’avorter la
transaction et de restaurer l’état initial de leurs ressources en envoyant
des messages de retour en arrière (R_en_Ar GR_ID). Cela permet aux
gestionnaires de ressources d’annuler les changements effectués au
niveau des ressources réservées pendant la "Phase de Validation". A la
fin de cette phase, ce gestionnaire inférieur entre dans l’état "Terminé".
La sous-transaction contrôlée par ce gestionnaire se termine en échec.
Phase de finalisation
Dans cette phase, le gestionnaire inférieur autorise tous les
gestionnaires de ressources associés à finaliser la transaction et rendre
ainsi les modifications apportées sur leurs ressources définitives. Pour
Mayyad JABER 157
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
cela, ce gestionnaire de transaction envoie des messages "Termine
GR_ID" à tous les gestionnaires de ressource associés. Cela permet aux
gestionnaires de ressources de rendre définitives les changements
effectués au niveau de ressources concernées pendant la "Phase de
Validation". A la fin de cette phase, le gestionnaire inférieur entre dans
l’état "Terminé". La sous-transaction contrôlée par ce gestionnaire se
termine avec Succès.
Mayyad JABER 158
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 159
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 160
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 7-12 Gestionnaire de transaction Inférieur
7.3.9 Rôle du gestionnaire de transaction "supérieur/inférieur"
Comme nous avons fait avec les gestionnaires de transaction de type
racine et inférieur, nous allons présenter les différents états possibles
pour un gestionnaire de transaction Supérieur/Inférieur dans une
transaction distribuée (Figure 7-13). Le gestionnaire supérieur/inférieur
joue le rôle d’un supérieur quand il s’agit de coordonner les tâches des
gestionnaires de niveau inférieur associés, et le rôle d’un inférieur vis-à-
vis de son gestionnaire de transaction supérieur. Après sa création, le
supérieur/inférieur envoie un message d’enregistrement "Enregistre
Inférieur_ID" au gestionnaire de niveau supérieur et entre ensuite dans
un état d’attente d’enregistrement (Atn_Enregistré).
Mayyad JABER 161
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Etat d’attente d’enregistrement (Atn_Enregistré)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
attend pour un message d’enregistrement de la part du gestionnaire de
niveau supérieur. On sort de cet état de deux manières :
Un trigger "Délai_dépassé" est déclenché avant la réception
du message d’enregistrement du gestionnaire de niveau
supérieur. Dans ce cas, le gestionnaire supérieur/inférieur
entre dans l’état "Terminé" et la sous-transaction contrôlée
par ce gestionnaire se termine en échec.
Le message d’enregistrement (Enregistré) du gestionnaire
de niveau supérieur est reçu. Dans ce cas, le gestionnaire
supérieur/inférieur débute la phase d’enregistrement des
sous gestionnaires associés et entre dans l’état
"Attente_Inférieur_ID".
Etat "Attente_Inférieur_ID"
Dans cet état, le gestionnaire de transaction supérieur/inférieur
reçoit les demandes d’enregistrement "Enregistre Inférieur_ID" des
gestionnaires de niveau inférieur pour être enregistrés comme des
participants dans la sous-transaction. Pour chaque gestionnaire de
niveau inférieur participant, le gestionnaire de transaction
supérieur/inférieur envoie un message de confirmation "Enregistré". On
sort de cet état de deux manières :
Une demande d’enregistrement (Enregistre Inférieur_Id) est
reçue. Lorsque tous les gestionnaires de niveau inférieur
concernés dans la sous transaction sont enregistrés, le
gestionnaire de transaction supérieur/inférieur quitte l’état
d’attente d’enregistrements par les gestionnaires inférieurs
associés "Attente_Inférieur_ID" et entre dans l’état
d’attente de décision du gestionnaire de niveau supérieur
"Atn_Prépare".
Un trigger "Délai_dépassé" est déclenché avant que tous les
gestionnaires de niveau inférieur soient enregistrés. Dans ce
cas, le service associé sera consulté pour déterminer si la
liste des gestionnaires de niveau inférieur enregistrés est
Mayyad JABER 162
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
suffisante. Pour cela, le gestionnaire supérieur/inférieur
envoie la liste des gestionnaires enregistrés
(Liste_Enregistré) au service associé et attend la réponse
état (Atn_WS_Réponse)
Etat d’attente de décision du service associé (Atn_WS_réponse)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
attend la décision du service associé sur la possibilité de se limiter à la
liste des gestionnaires de niveau inférieur enregistrés. On sort de cet état
grâce à trois sorties :
Un trigger "Délai_dépassé" se produit. Le gestionnaire
supérieur/inférieur entame la phase d’avortement
(Avorte_Transaction).
Un message d’abandon (Avorte) est reçu venant du service
associé. Le gestionnaire supérieur/inférieur entame la phase
(Avorte_Transaction).
Le supérieur/inférieur reçoit un message "Continue" de la
part du service associé. Le supérieur/inférieur entre dans
l’état d’attente de décision du gestionnaire de niveau
supérieur "Atn_Prépare".
Etat d’attente de décision du gestionnaire de niveau supérieur
"Atn_Prépare"
Dans cet état, le gestionnaire de transaction Supérieur/Inférieur
attend l’ordre de préparation (message "Prépare Inférieur_ID") de la part
du gestionnaire de niveau supérieur. On sort de cet état grâce à trois
sorties :
Un trigger "Délai_dépassé" est déclenché avant la réception
du message "Prépare Inférieur_ID" du gestionnaire de
niveau supérieur. Dans ce cas, le Supérieur/Inférieur
entame la phase d’abandon (Avorte_Transaction) et la sous-
transaction contrôlée par ce supérieur/inférieur se termine
en échec.
Le message "Avorte Inférieur_ID" du gestionnaire de
niveau supérieur est reçu. Dans ce cas, le gestionnaire
Mayyad JABER 163
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
supérieur/Inférieur entame la phase d’abandon
(Avorte_Transaction) et la sous-transaction contrôlée par ce
supérieur/inférieur se termine en échec.
L’ordre de préparation "Prépare Inférieur_ID" du
gestionnaire supérieur est reçu. Dans ce cas, le
supérieur/inférieur entame la phase de préparation.
Phase de préparation
Dans cette phase, le gestionnaire de transaction
supérieur/inférieur ordonne à tous les gestionnaires de niveau inférieur
enregistrés de se préparer pour l’exécution des sous-transactions. Il
envoie des messages de demandes de préparation
"Prépare_Inférieur_ID" à tous les gestionnaires de niveau inférieur
enregistrés. Ensuite, il entre dans l’état d’attente des réponses des
gestionnaires de niveau inférieur (Atn_Infs_prêts).
Etat d’attente des réponses des inférieurs (Atn_Infs_prêts)
Le gestionnaire de transaction supérieur/inférieur reçoit les
réponses des gestionnaires de niveau inférieur à son ordre de préparation
(Prépare_Inférieur_ID). On sort de cet état de trois manières :
Une réponse négative (Insuffisance_Inférieur_ID) est reçue.
Si le gestionnaire de niveau inférieur qui l’envoyé
appartient au groupe de veto, le supérieur/inférieur envoie
un message "Insuffisance" au gestionnaire de niveau
supérieur et entame ensuite la phase "Avorte Transaction".
Si le gestionnaire de niveau inférieur à l’origine de réponse
négative n’appartient pas au groupe de veto, sa réponse est
enregistrée. Lorsque tous les gestionnaires de niveau
inférieur ont répondu (positivement ou négativement), une
liste des gestionnaires de niveau inférieur prêts
(Liste_prêts) est envoyée au service associé et le
gestionnaire de transaction supérieur/inférieur entre dans
l’état d’attente de validation par le service associé
(Atn_WS_Valide).
Un trigger "Délai_dépassé" se produit avant la réception de
toutes les réponses des gestionnaires de niveau inférieur.
Mayyad JABER 164
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Dans ce cas, le service associé sera consulté pour
déterminer si la liste des gestionnaires de niveau inférieur
prêts est suffisante pour valider (commit) la transaction.
Pour ce faire, une liste des gestionnaires de niveau inférieur
prêts "Liste_prêts" est envoyée au service associé et le
gestionnaire de transaction supérieur/inférieur entre dans
l’état d’attente de validation par le service associé
(Atn_WS_Valide).
Une réponse positive est reçue (Prêt_Inférieur_ID) et
enregistrée. Lorsque tous les gestionnaires de niveau
inférieur ont répondu (positivement ou négativement), une
liste des gestionnaires de niveau inférieur prêts
(Liste_prêts) est envoyée au service associé et le
gestionnaire de transaction supérieur/inférieur entre dans
l’état d’attente de validation par le service associé
(Atn_WS_Valide).
Etat d’attente de validation du service associé (Atn_WS_Valide)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
attend la décision du service associé sur la liste des gestionnaires de
niveau inférieur prêts. On sort de cet état grâce à trois sorties :
Un trigger "Délai_dépassé" se produit. Le gestionnaire
supérieur/inférieur envoie un message "Insuffisance" au
gestionnaire de niveau supérieur et entame la phase
d’avortement (Avorte_Transaction).
Un message d’abandon (Avorte) est reçu de la part du
service associé. Le gestionnaire supérieur/inférieur envoie
un message "Insuffisance" au gestionnaire de niveau
supérieur et entame la phase (Avorte_Transaction).
Le supérieur/inférieur reçoit un message de validation
(Valide) de la part du service associé. Le supérieur/inférieur
entre dans l’état d’attente de décision du gestionnaire de
niveau supérieur "Atn_Valide".
Mayyad JABER 165
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Etat d’attente de validation (Atn_Valide)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
attend la décision du gestionnaire de niveau supérieur sur la poursuite de
la transaction. On sort de cet état de trois manières :
Un trigger "Délai_dépassé" se produit. Le
supérieur/inférieur envoie un message "Délai_dépassé" au
gestionnaire de niveau supérieur et entame ensuite la phase
d’abandon (Avorte_Transaction).
Le supérieur/inférieur reçoit un message d’abandon (Avorte
Inférieur_Id) de la part du gestionnaire de niveau supérieur.
Le supérieur/inférieur entame la phase d’abandon
(Avorte_Transaction).
Le gestionnaire supérieur/inférieur reçoit un message de
validation (Valide Inférieur_Id) de la part du gestionnaire
de niveau supérieur. Le supérieur/inférieur entame la phase
de validation.
Phase d’abandon (Avorte Transaction)
Dans cette phase, le gestionnaire de transaction
supérieur/inférieur ordonne à tous les gestionnaires de niveau inférieur
d’avorter la transaction. Il envoie des messages d’abandon
(Avorte_Inférieur_ID) à tous les gestionnaires inférieurs de sa liste. A la
fin de cette phase, le supérieur/inférieur entre dans l’état "Terminé" et la
sous-transaction se termine en échec.
Phase de Validation
Dans cette phase, le gestionnaire de transaction
supérieur/inférieur ordonne à tous les gestionnaires de niveau inférieur
prêts de valider l’exécution (commit) de la sous-transaction. Il envoie
des messages de validation (Valide_Inférieur_ID) à tous les
gestionnaires de niveau inférieur de sa liste. Ensuite, il entre dans l’état
d’attente de fin de transaction (Atn_Accompli).
Etat d’attente de fin de transaction (Atn_Accompli)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
reçoit les réponses des gestionnaires de niveau inférieur à ses messages
Mayyad JABER 166
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
de validation (Valide_Inférieur_ID). On sort de cet état de trois
manières :
Une réponse négative (Echec_Inférieur_ID) est reçue. Le
gestionnaire supérieur/inférieur envoie un message "Echec"
au gestionnaire de niveau supérieur et entame ensuite la
phase de retour en arrière.
Un trigger "Délai_dépassé" se produit avant la réception de
toutes les réponses des gestionnaires de niveau inférieur.
Dans ce cas, le supérieur/inférieur envoie un message
"Echec" au gestionnaire de niveau supérieur et entame
ensuite la phase de retour en arrière.
Une réponse positive (Accompli_Inférieur_Id) est reçue.
Lorsque tous les gestionnaires de niveau inférieur de la liste
ont répondu, le supérieur/inférieur envoie un message
indiquant la validation de la transaction dont il avait la
charge (Accompli_Inférieur_ID) et entre ensuite dans l’état
d’attente de la confirmation de la transaction
(Atn_Termine).
Etat d’attente de la confirmation de la transaction (Atn_Termine)
Dans cet état, le gestionnaire de transaction supérieur/inférieur
attend la décision du gestionnaire de niveau supérieur. On sort de cet
état de trois manières :
Un trigger "Délai_dépassé" se produit. Le
supérieur/inférieur envoie un message "Délai_dépassé" au
gestionnaire de niveau supérieur et entame la "Phase de
Retour en Arrière".
Le supérieur/inférieur reçoit un message lui ordonnant le
retour en arrière (R_en_A Inférieur_ID) de la part du
gestionnaire de niveau supérieur. Le supérieur/inférieur
entame la "Phase de Retour en Arrière".
Le supérieur/inférieur reçoit un message de finalisation
(Termine Inférieur_ID) de la part du gestionnaire de niveau
supérieur. Le gestionnaire supérieur/inférieur entame la
phase de finalisation.
Mayyad JABER 167
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Phase de retour en arrière
Dans cette phase, le gestionnaire de transaction
supérieur/inférieur ordonne à tous les gestionnaires de niveau inférieur
de restaurer leur état initial. Pour cela, il envoie des messages de
Retour_en_Arrière (R_en_Ar Inférieur_ID) à tous les gestionnaires de
niveau inférieur qui ont accompli leur tâches puis il entre dans l’état
"Terminé".
Phase de finalisation
Dans cette phase, le gestionnaire de transaction
supérieur/inférieur ordonne à tous les gestionnaires de niveau inférieur
de terminer la transaction. Il envoie des messages de fin
(Termine_Inférieur_ID) à tous les gestionnaires de niveau inférieur de
sa liste et entre dans l’état "Terminé". Dans ce cas, les modifications
apportées sur les ressources seront définitives et la transaction se
termine avec succès.
Mayyad JABER 168
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 169
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mayyad JABER 170
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 7-13 Gestionnaire de transaction Supérieur/Inférieur
Mayyad JABER 171
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
7.4 Conclusion
L’exécution du processus commun interentreprises lâchement couplé
dans un environnement peu fiable tel que le Web nécessite des facilités
spécifiques pour renforcer la fiabilité. Le défi est de garantir une gestion
agile de ressources distribuées (rendues accessibles pour des entités de
business externes par le biais de services Web). A cet effet, nous avons
introduit un mécanisme d’allocation de ressources distribuées qui prend
en compte les événements imprévus issus des pannes matérielles ou
logiciels. En plus, et en raison de la nature distribuée du processus
commun, le mécanisme d’allocation de ressources proposé est capable
de traiter les conflits et l’interblocage issus de demandes concourantes
d’accès aux ressources.
Afin de supporter la cohérence et la durabilité du processus
commun, nous avons proposé un système de gestion de transactions
distribuées permettant de surveiller et de coordonner les actions des
sous-processus engagés dans une transaction globale. Ce système est
basé sur une hiérarchie de gestionnaires de transactions associées à
chaque service participant au processus commun. Après avoir présenté
le mode d’exécution du processus commun en trois phases, nous avons
expliqué en détail les rôles de chaque gestionnaire dans le processus
commun.
La conception du processus commun que nous avons développé
tout au long de ce travail est basée sur un assemblage des services
recomposables de manière dynamique. A cet effet, et afin de garder la
flexibilité du processus commun, le système de gestion de transactions
distribuées proposé dans ce chapitre doit être intégré dynamiquement.
Plus précisément, l’association des gestionnaires de transactions avec les
services Web constituant le processus commun ne peut pas être en
"dure". Afin de montrer comment intégrer dynamiquement les
gestionnaires de transactions distribuées dans le processus commun,
nous allons, nous allons consacrer le chapitre suivant pour définir une
architecture prototype dédiée pour la mise en place du processus
commun transactionnel.
Mayyad JABER 172
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 8 Implémentation du système
gestionnaire de transaction
8.1 Introduction
Dans ce travail, nous avons présenté une architecture distribuée orientée
service qui permet la mise en œuvre d’un système d’information dédié
pour la gestion de la chaîne logistique. Le système visé est construit à
partir de services distribués permettant l’accès aux processus privés et
ainsi aux ressources distribuées nécessaires pour l’exécution du
processus commun de la chaîne logistique. Afin d’harmoniser l’accès
aux ressources et garantir un résultat cohérant pour le processus
commun, nous avons intégré un système de gestion de transaction
distribué. Ce système permet de renforcer la fiabilité du processus
commun de la chaîne logistique durant la phase d’exécution. A cet effet,
nous avons décrit une architecture de contrôle hiérarchique basée sur des
gestionnaires de transaction indépendants.
Dans ce chapitre, nous proposons une architecture pour
l’implémentation d’un prototype du processus commun en se basant sur
la vision que nous avons développée tout au long de ce travail et tenant
compte des contraintes propres au contexte de collaboration
interentreprises, à savoir des recombinaisons contextuelles d’objets et
services métiers selon des règles de gestion variable. Cette contrainte
d’agilité empêche d’embarquer les éléments relatifs à la gestion de
transaction dans les objets de business et services offerts puisque le
statut de ces composants (supérieur ou inférieur) peut changer en
fonction des règles de décision présidant à de la composition de services
dans le Workflow associé au processus commun. Ceci nous conduit donc
à proposer une implémentation sous forme de services recomposables en
Mayyad JABER 173
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
fonction du contexte défini par l’organisation même du processus
commun.
A cet effet nous présentons les notions concernant la plate-
forme de développement que nous utilisons pour la construction du
processus commun. Nous détaillerons les modules de la plate-forme qui
sont nécessaires pour la mise en place de chaque élément de processus
commun (services Web, Workflow global, gestionnaires de
transactions).
Normalement, les services distribués sont implémentés et
publiés par les entités de business. Nous allons implémenter les
gestionnaires de transactions comme des services distribués. Cela
permet leur intégration dans le processus commun et ainsi leur
orchestration par le biais du moteur de Workflow offert par la plate-
forme.
8.2 Cahier de charge
Selon l’architecture proposée dans ce travail, le processus commun est
bâti en se basant sur les éléments suivants :
Les services distribués : ce sont les composants constituant la
structure de base pour le processus commun.
Les gestionnaires de transactions distribuées : ils contrôlent
l’exécution du processus commun afin de garantir un résultat
cohérent.
Le moteur de Workflow global : il assure l’orchestration de
l’ensemble de composants du processus commun (services distribués
et gestionnaires de transactions).
Afin de développer une application dans le domaine du B2B,
nous cherchons des outils et des approches requis pour le développement
d’applications de type Web. La plate-forme recherchée s’agit d’un
serveur d’application qui fournit les dispositifs suivants :
Les outils nécessaires pour le développement et le déploiement de
services Web y compris un registre pour la publication de services.
Un orchestrateur de services Web distribués permettant leur
exécution sous forme de Workflow global.
Un système de gestion de transactions distribuées.
Mayyad JABER 174
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
La Figure 8-1 montre une architecture intégrant des composants
du marché l’architecture du marché destinée à la mise en œuvre du
processus commun interentreprises. Cette architecture utilise un serveur
d’applications offrant un environnement qui regroupe les trois modules
constituant l’architecture :
Module de gestion de services Web : ce module permet la
publication et la mise en œuvre de services Web. Ce module peut
être utilisé par les entités de business pour construire les services
nécessaires afin d’externaliser leurs processus métier internes.
Module de gestion de transaction : ce module est dédié pour assurer
une exécution cohérente du processus commun lâchement couplé. Il
fournit les facilités nécessaires pour contrôler l’exécution de
services Web constituant le processus commun transactionnel.
Module d’orchestration : le rôle de ce module est d’assurer
l’orchestration de services Web mais aussi des gestionnaires de
transaction associés dans un processus commun transactionnel.
Mayyad JABER 175
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 8-1 Architecture du marché destinée à supporter le processus commun
Pour faire face aux contraintes d’interopérabilité, nous
privilégions une approche basée sur des « standards du marché » et
permettant aussi de rester indépendant de fournisseurs de logiciels. En
ce qui concerne le choix technique, la plate-forme Java peut offrir les
exigences nécessaires pour bâtir une telle architecture. Pourtant il existe
des plates-formes qui sont mieux adaptées au développement et au
déploiement des applications dynamiques du Web. Nous avons
concentré nos recherches afin de trouver une plate-forme adaptée pour
réaliser cette architecture, plateforme qui offre aussi un serveur
d’applications "open source" de niveau professionnel. Dans le
paragraphe suivant, nous présentons notre étude sur les plates-formes du
marché qui offrent les composants nécessaires pour la mise en place et
la mise en œuvre du processus commun interentreprises.
Mo
du
le d
e g
estio
n d
e se
rvic
es W
eb
Mo
du
le d
e g
estio
n d
e
tran
sactio
ns d
istribu
ées
Processus commun interentreprises
Module d’orchestration
Serv
eu
r d’a
pp
licatio
n
Mayyad JABER 176
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
8.3 Plates-formes existantes
La plate-forme que nous visons pour l’implémentation du prototype doit
permettre le développement et la mise en œuvre d’une application de
type SOA répartie sur le Web. L’application résultante doit s’adapter
aux systèmes d’information patrimoniaux de chaque entreprise
participant à la chaîne logistique.
L’évaluation des produits et des technologies utilisés dans la
plate-forme a été basée sur différents critères tels que la flexibilité, la
capacité de supporter les processus métier, et l’existence d’outils de
développement efficaces pour obtenir une plateforme robuste et
extensible (pour faciliter la mise en place de processus d ’amélioration et
de maintenance des services constituant les composants du système
d’information interentreprises). A cet effet, les plates-formes basées sur
Java sont les mieux adaptées. Ce choix s’explique principalement par les
raisons suivantes :
Les innovations dans les versions récentes, telles que les EJB, ont
apporté une grande flexibilité pour les développeurs.
Les technologies "orientées entreprise" comme J2EE, EJB, JPA,
JMS, JSF, etc. sont très efficaces et permettent d’augmenter la
vitesse de développement
L’existence d’environnements de développement (IDE - Integrated
Development Environment) puissants comme Eclipse et NetBeans
favorisent également un développement rapide.
L’existence de bibliothèques de logiciels ouverts et libres pour la
plateforme de Java correspond à notre choix de base pour
l’architecture.
Parmi les plates-formes existantes dans le marché (Jboss,
JOnAS, Resin, JRun, Oracle IAS, BEA WebLogic Server, IBM
WebSphere, …) nous avons ciblé notre recherche sur une plate-forme
"open source" pour deux raisons :
Eviter les surcoûts nécessaires pour acquérir une licence et utiliser
une plate-forme au porté des PMEs.
Mayyad JABER 177
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Utiliser une plate-forme modulaire (reconfigurable) permettant
l’intégration de nos propositions concernant la mise en place de
processus commun.
Au terme de notre recherche, les plates-formes qui sont
adaptées pour répondre à nos exigences ("open sources", licence à coût
zéro, performance) sont JBoss et JOnAS. Le Tableau 8-1 présente une
comparaison entre JBoss et JOnAS.
Tableau 8-1 JBoss vs. JonAS
Critère JOnAS JBoss
Open source ✔ ✔
Certification J2EE ✔ ✔
Support de processus métier
et de Workflow ✕ jBPM
Développement et gestion
de services Web ✕ JBossWS
Support pour les
transactions distribuées JOTM JBoss Transactions
Interopérabilité et standards
ouverts ✔ ✔
Support technique ✔ ✔✔
Documentation ✔ ✔✔
Plugins pour Eclipse ✕ ✔
Performance Demande réduite de
ressources
Amélioré par JBoss
Cache
Mayyad JABER 178
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Suite à cette comparaison, nous avons choisi JBoss pour
développer notre architecture prototype. Ce choix est justifié par le fait
que JBoss offre un support pour les processus métiers, le Workflow, et
les services Web, ce qui n’est pas le cas pour JOnAS comme nous
pouvons constater sur le Tableau 8-1.
8.4 JBoss
JBoss offre des composants de technologie de haute qualité que les
clients peuvent utiliser dans leur infrastructure, avec une licence de
logiciel à « coût zéro ». L’ensemble du logiciel dédié pour l’entreprise
de JBoss (JEMS) est une plateforme "open source". C’est un pack
extensible de produits pour la création et le déploiement d ’applications
de e-business basées sur des architectures orientées service [JBoss,
2007b].
JBoss JEMS est le leader des serveurs d’application pour J2EE.
Il supporte les nouvelles fonctionnalités de J2EE. Les produits
indépendants de JBoss, comme le jBPM (JBoss Business Processes
Managemnet) et JBoss transactions peuvent offrir des outils efficaces
pour la construction des composants de l’architecture cadre que nous
proposons. Les composants résultants peuvent être déployés sur "JBoss
AS" mais également sur d’autres plateformes J2EE, offrant la flexibilité
requise dans le contexte de la chaîne logistique.
Le serveur d’application JBoss (JBoss AS) est l’un des serveurs
d’application Java les plus employés sur le marché. C’est une plateforme
certifiée par J2EE pour le développement et le déploiement
d’applications Java pour l’entreprise, d’applications de Web et de
portails. JBoss AS fournit la gamme complète des dispositifs de J2EE et
des services nécessaires dans le contexte des entreprises étendues
comme l’assemblage de services distribués.
En outre, JBoss utilise Eclipse IDE comme environnement de
développement intégré. Conçu pour l’usage avec le système de logiciel
personnalisé d’entreprise de JBoss (JEMS), Eclipse IDE de JBoss offre
une série de plugins intégrés d’Eclipse pour bâtir des applications de
qualité. Eclipse IDE de JBoss prolonge Eclipse et permet aux
programmeurs de développer, déployer, examiner et corriger leurs
applications basées sur JEMS sans avoir besoin d’autres outils. En
Mayyad JABER 179
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
simplifiant le cycle de vie de développement, Eclipse IDE de JBoss
permet de fournir des applications ayant une forte valeur ajoutée en un
minimum de temps. Un développement plus rapide, combiné à l’absence
de coûts de licence réduit considérablement les coûts globaux liés à la
création d’applications d’entreprise [JBoss, 2005].
Les paragraphes suivants portent sur les différents composants
de la plate-forme JBoss qui sont utile à notre prototype.
8.4.1 Processus métier et orchestration : jBPM
En ce qui concerne le niveau métier, JBoss fournit un moteur de règles
métiers standardisées qui permet l’accès, le changement et la gestion
faciles de politique de business. JBoss offre un outil de développement
rapide et efficace qui facilite le fait de regarder les règles de business
comme elles sont codées dans l’infrastructure d’application. Ce faisant,
la tâche de vérification que les règles codées mettent en application les
politiques business documentées devient plus facile. Les règles de JBoss
comportent également une variété de langages facilitant les
modifications des politiques de business pour répondre aux opportunités
du marché [JBoss, 2006].
Le composant jBPM (JBoss Business Process Management) de
JBoss permet la création des processus métiers coordonnant les activités
métiers qui sont supportées par les applications et les services des
entreprises indépendantes. Conçu pour le marché grand public aussi bien
que pour des applications support au niveau de grandes entreprises,
jBPM supporte l’automatisation de processus de la gestion de
Workflows embarqués jusqu’à l’orchestration de processus métier
d’entreprise. Aujourd’hui, jBPM de JBoss supporte deux langages
orientés processus :
Le jPDL (langage de définition de processus de jBPM) est un
langage de description de processus pour mettre en application le
BPM et le Workflow dans Java. jPDL combine la supervision des
tâches humaines avec la construction des processus de Workflow qui
peuvent être établis dans des applications Java [JBoss, 2006].
BPEL (Business Process Execution Language) supporte
l’orchestration de processus du fait de sa capacité de combiner des
Mayyad JABER 180
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Services Web dans l’exécution d’un flux de processus [JBoss,
2007a].
8.4.2 Gestion de services Web : JBoss WS
JBoss AS a introduit le modèle de programmation EJB 3.0 qui rendu
possible la création et la consommation de services Web par JBoss. Il
s’agit d’un cadre de services Web qui implémente la spécification JAX-
WS. Ce cadre définit un modèle de programmation et un environnement
d’exécution pour l’implémentation de services Web en Java. JBoss WS
permet aux entreprises d’implémenter les services Web nécessaires pour
accéder à leurs processus métiers locaux. Les services Web résultants ne
sont pas limités à la plate-forme JBoss, ils sont destinés à une plate-
forme Java [JBoss, 2007b].
8.4.3 Gestion de transactions : JBoss Transactions
En ce qui concerne la gestion de transactions JBoss offre le composant
"JBoss transactions". C’est une plateforme certifiée de gestion de
transactions. Elle est destinée pour bâtir des solutions qui exigent
l’interopérabilité et l’intégrité entre les composants d’application qui
mettent à jour des ressources réparties dans différents systèmes et bases
de données. Construit sur la technologie de gestion de transactions de
Java, la gestion de transactions de JBoss offre un traitement
transactionnel pour les applications basées sur des Services Web [JBoss,
2007c].
8.4.4 Discussion
"JBoss AS" offre les composants nécessaires pour les entreprises afin de
bâtir et de déployer des services dédiés pour supporter les processus
interentreprises. Les services résultants sont plate-forme indépendants et
peuvent ainsi être déployés sur d’autres plates-formes java. Cela permet
leur interopérabilité et leur portabilité à travers les systèmes
d’information des partenaires de la chaîne logistique. Outre, le jBPM
permet l’orchestration de services distribués par l’automatisation du
processus de la gestion de Workflow global. Cela est réalisé par le biais
Mayyad JABER 181
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
de langages orientés processus (jPDL, BPEL). Au niveau de la gestion
de transactions distribuées, "JBoss transactions" supporte les
transactions de services Web basées sur la validation en deux phases
(section 4.5.2). De ce fait, ce dispositif n’est pas convenable pour bâtir
le système de transactions avec la validation en trois phases et la notion
de veto-set que nous proposons. A cet effet, nous avons utilisé les
dispositifs offerts par JBoss pour implémenter les gestionnaires de
transactions comme des services Web. Ainsi, le module de gestion de
transaction présenté dans la section 8.2 sera intégré avec le module de
gestion de services Web. Ainsi, les gestionnaires de transactions seront
bâtis en se basant sur les dispositifs de la plate-forme comme des
composants indépendants. L’ensemble de services métiers et les services
dédiés pour la gestion de transactions distribuées sont ensuite orchestrés
par le biais de l’orchestrateur de la plate-forme. La Figure 8-2 représente
l’architecture modifiée de la plateforme présentée dans la section 8.2.
Figure 8-2 Architecture modifiée de la plate-forme
8.5 Etude de cas
En se basant sur cette architecture de plate-forme type, nous visons la
construction d’un prototype de processus commun transactionnel qui
implémente les principes du système de gestion de transactions
Module de gestion de services
et de gestionnaires de
transactions
Processus commun interentreprises
Module d’orchestration
Serv
eu
r d’a
pp
licatio
n
Mayyad JABER 182
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
distribuées proposé dans le Chapitre 7. Nous proposons un processus
interentreprises composé à partir de services distribués proposés par des
entreprises membres de la chaîne logistique. Le processus de
composition du processus commun fait le sujet des autres travaux menés
dans notre laboratoire [Chaari, 2008].
Afin de clarifier le mode de fonctionnement du prototype, nous
reprenons l’exemple du processus commun qui correspond à l’étude de
cas "e-approvisionnement" présentée dans la section 5.4.1.4. Nous
mettons l’accent sur les processus publics de chaque entité de business
participant à la chaîne logistique. Les processus publics seront intégrés
dans le processus commun et nous identifions les services Web supports
des processus publics pour chaque entité de business engagée dans le
processus commun (les services sont illustrés dans la colonne à droite de
la Figure 8-3) :
Client
o Service 1 : c’est le service support du processus d’achat chez
le client. Il s’agit du service initiateur du processus commun.
Ce service est invoqué par un processus privé du client. Il
invoque le service qui assure le traitement des ordres d ’achat
chez le fabricant (service 2).
Fabricant
o Service 2 : c’est le service support du processus de
traitement des ordres d’achat. Ce service est invoqué par le
service 1.
o Service 3 : c’est le service support du processus des
demandes de devis concernant les matières premières chez le
fabricant. Selon les règles de gestions expliquées dans la
section 5.4.1.4, le service 3 peut être invoqué par un
processus privé chez le fabricant à l’issue de l’exécution de
service 2.
Fournisseur 1
o Service 4 : c’est le service support du processus de
traitement des demandes de devis chez le fournisseur 1.
Fournisseur 2
o Service 5 : c’est le service support du processus de
traitement des demandes de devis chez le fournisseur 2.
Fournisseur 3
Mayyad JABER 183
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
o Service 6 : c’est le service support du processus de
traitement des demandes de devis chez le fournisseur 3.
Figure 8-3 Services Web participant au processus commun d ’e-
approvisionnement
Mayyad JABER 184
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Le processus commun d’e-approvisionnement est composé à
partir des services Web distribués mentionnés ci-dessus. Selon les règles
de gestion, nous constatons que le processus commun (et donc les
transactions qui seront associées aux services) peut avoir plusieurs
configurations. Ces configurations sont illustrées dans la Figure 8-4.
Figure 8-4 Différentes configurations pour le processus commun d’e-
approvisionnement
Du point de vue technique, la variation de la configuration du
processus commun impose une composition flexible. Cela est réalisé en
fournissant au module d’orchestration les services Web sous forme de
fichiers WSDL avec la définition du processus commun. En outre, cette
variabilité de configuration impose une intégration dynamique de
gestionnaires de transaction au sein du processus commun. Dans le reste
de ce chapitre nous traitons le problème de l’intégration de système de
gestion de transactions distribuées.
Mayyad JABER 185
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
8.6 Prototype d’architecture
Comme nous l’avons déjà indiqué, le processus commun que nous
proposons se compose d’un ensemble de services Web orchestrés par un
Workflow global. Dans le cadre d’un processus commun transactionnel,
chaque service participant est associé à un gestionnaire de transaction
pour contrôler son exécution. Pour ce faire, nous implémentons un
composant "factory" dont le rôle est de créer les instances de
gestionnaires de transaction suite aux demandes de services concernés
(Figure 8-5). En se basant sur les outils et les composants présentés ci-
dessus nous allons implémenter les différents gestionnaires de
transactions (racine, supérieur/inférieur, inférieur). Ces gestionnaires
peuvent être intégrés dans un processus transactionnel et orchestré avec
les services Web participant par le biais de jBPL. Pour cela, les services
Web participants dans le processus commun doivent fournir (en plus de
leurs fonctionnalités ordinaires) les fonctionnalités suivantes :
Invoquer le factory pour demander la création d’un gestionnaire de
transaction qui correspond au niveau du service dans la hiérarchie de
la transaction.
Fournir la liste des services Web de niveau inférieur au gestionnaire
de transaction associé (le cas échéant) ainsi que le(les) inférieur(s)
faisant partie du veto-set.
Décider de la continuité de la transaction dans le cas où une partie
des gestionnaires de niveau inférieur annonce une réponse négative.
Fournir les délais d’attente maximale quand le gestionnaire associé
entre dans un état d’attente durant l’exécution du processus
commun.
Dans la suite, nous citons les interfaces d’échanges entre
gestionnaires et les échanges entre les gestionnaires et les services
Web :
recevoirGestionnaire(message, infID) : permet de recevoir un
message d’un gestionnaire de niveau inférieur
recevoirWebService(message, serviceID) : permet de recevoir un
message du service Web associé
Mayyad JABER 186
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 8-5 Rôle du composant factory dans le processus commun
transactionnel
enregistre(infID, list) : permet d’enregistrer la réponse d’un
gestionnaire de niveau inférieur dans la liste concernée (Liste
prêts par exemple).
recevoirInsuffisant(infID) : permet à un gestionnaire de niveau
supérieur de prendre en compte le fait qu’une exception
concernant un gestionnaire de niveau inférieur a eu lieu durant la
phase de validation.
envoyerGestionnaire(message, infID) : permet d’envoyer un
message à un gestionnaire de niveau inférieur.
envoyerServiceWeb(list, serviceID) : permet d’envoyer la liste
des gestionnaires inférieurs (enregistrés, prêts) au service Web
associés.
notifierSuperieur(message, SuperieurID) : permet à un
gestionnaire de niveau inférieur de communiquer un message à
son supérieur.
Mayyad JABER 187
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Afin de montrer les différentes étapes de l’exécution du
processus commun, nous introduisons un diagramme de séquence
intégrant les différents acteurs du processus commun (Figure 8-6).
Mayyad JABER 188
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 8-6 Diagramme de séquence pour les composants du processus
commun
Mayyad JABER 189
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
8.7 Résultats
La mise en place de cette architecture offre une solution flexible et agile
pour configurer dynamiquement la gestion de transaction distribuée en
fonction de la configuration du processus commun. L’étude de cas que
nous avons retenue montre que chaque service participant au processus
commun doit s’associer à un gestionnaire de transaction (racine,
supérieur/inférieur ou inférieur) selon son rôle dans le processus
commun. La Figure 8-7 montre l’intégration des gestionnaires de
transaction dans le processus commun d’e-approvisionnement. Cette
intégration montre qu’un gestionnaire associé à un service peut jouer
différents rôles selon la configuration du processus commun. Par
exemple, le gestionnaire G2 associé au service 1 joue le rôle d ’un
inférieur dans la première configuration et le rôle d ’un supérieur dans la
deuxième configuration. Cela implique le besoin d’une association
dynamique pour les gestionnaires de transactions avec les services Web.
A cet effet, chaque service fait un appel au "factory" dont le rôle est de
générer le gestionnaire correspondant sous forme de service Web selon
les paramètres fournis par le service concerné via l’interface de factory.
Le factory génère la description du service qui implémente le
gestionnaire sous forme de fichier WSDL. En se basant de la définition
du processus commun, les fichiers WSDL des services constituant le
processus commun avec les fichiers WSDL des gestionnaires de
transactions forment les entrées de l’orchestrateur pour générer les
fichiers BPEL qui définissent le processus commun transactionnel.
Mayyad JABER 190
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Figure 8-7 Intégration des gestionnaires de transaction dans les differentes
configurations du processus d’e-approvisionnement
Mayyad JABER 191
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
A ce stade de notre travail, nous présentons la structure du
composant factory ainsi que les différents gestionnaires de transactions
résultant. La Figure 8-8 montre la structure du fichier WSDL pour le
factory. Le fichier WSDL du factory ainsi que les autres fichiers WSDL
pour les gestionnaires de transactions (racine, supérieur/inférieur,
inférieur) sont fournis dans l’annexe A.
Figure 8-8 Structure du fichier WSDL pour le factory
8.8 Conclusion
La mise en œuvre du processus interentreprises proposé dans notre
travail nécessite une plate-forme adaptée pour le domaine de B2B. Dans
ce chapitre nous avons présenté une architecture de plate-forme type
avec les détails des modules nécessaires pour la mise en place du
processus commun. Nous avons ensuite effectué une recherche sur les
plates-formes existantes dans le marché. Nous avons ciblé notre
recherche sur les plates-formes open source avec un coût de licence à
zéro. Au bout de notre étude, nous avons retenu la plate-forme de JBoss
pour la mise en œuvre du prototype. JBoss offre les dispositifs requis
pour bâtir le processus commun, par contre, et en ce qui concerne la
gestion de transaction, le module proposé (JBoss transactions) supporte
les transactions basées sur la validation en deux phases. A cet effet, et
afin d’intégrer le système de gestion de transactions que nous avons
proposé dans le Chapitre 8, nous avons proposé d’implémenter les
gestionnaires de transactions (racine, inférieur et supérieur/inférieur)
Mayyad JABER 192
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
comme des services Web en se basant sur les dispositifs offerts par
JBoss. Nous avons appliqué notre solution sur une étude de cas d ’e-
approvisionnement en intégrant les gestionnaires de transactions de
manière dynamique.
Mayyad JABER 193
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Chapitre 9 Conclusion générale et
perspectives
Le cadre de notre travail se situe entre deux domaines composites : la
chaîne logistique et les systèmes d’information distribués
interentreprises. A cet effet, nous avons commencé par présenter l’état
de l’art et les différents aspects concernant les deux domaines. Nous
avons exploré le champ (chaîne logistique, systèmes d’information
distribués) afin de définir le cahier de charge du système visé et poser
les problématiques (besoin d’un support d’échange, interopérabilité de
systèmes hétérogènes, ….) et proposer les solutions (la feuil de route, le
cadre de type SOA, l’intégration du système de gestion de transactions
distribuées ….).
Sur l’axe de la chaîne logistique, nous avons posé l’état de l’art
de la chaîne logistique et le besoin de collaboration entre-partenaires en
vue d’améliorer la performance globale. Pour cela, nous avons montré
les éléments essentiels de la SC avec les paramètres de performance (le
temps, le coût, le rendement) ainsi que les méthodologies de calcul de la
performance. Nous avons montré aussi l’impact du système
d’information support du processus interentreprises sur la performance
globale de la chaîne logistique.
Avant d’attaquer les aspects techniques, nous avons présenté
les notions du processus métier et le Workflow comme un outil
d’automatisation de processus métier. Ces notions formeront les
concepts de base de notre architecture cadre. Subséquemment, les
aspects liés aux processus métier et le Workflow ont été présentés en
détail tout au long du Chapitre 3. En se basant sur ces notions, nous
avons introduit l’application de l’approche basée sur le processus métier
dans le domaine de la chaîne logistique pour organiser le processus
commun.
Mayyad JABER 194
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
En ce qui concerne les aspects techniques liés au système
d’information support de la chaîne logistique, nous avons abordé l’axe
de systèmes d’information distribués interentreprises (EDI,
CORBA,….). Évidemment ces systèmes représentent les systèmes
d’échange classiques. Nous avons montré les failles associées à ces
systèmes empêchant leur utilisation pour supporter le processus commun
interentreprises. En effet, la nature flexible de la chaîne logistique
impose un système agile, à base de composants lâchement couplés,
dédié à soutenir la collaboration interentreprises au sein de la chaîne
logistique. A cet effet, nous avons abordé les principes de l’architecture
orientée services comme un concept de base pour le IS visé et dans une
deuxième étape, nous avons montré en quoi la SOA est plus adéquate
pour les systèmes d’information interentreprises. Cela nous a conduit, au
niveau d’implémentation, d’expliquer les standards liés aux services
Web (XML, SOAP, WSDL, UDDI,….). Outre, la nature du système visé
(couplage lâche) et l’environnement d’exécution peu fiable impose
d’intégrer des moyens pour améliorer la fiabilité du processus commun.
De ce fait nous avons introduit les aspects de transaction (transactions
atomiques et validation en deux phases).
En se basant sur l’organisation du processus métier présentée
dans le Chapitre 3, et les principes de l’architecture orientée service
présentée dans le Chapitre 4 nous avons proposé une feuille de route
pour une architecture cadre permettant la construction d ’un système
d’information distribué dédié pour supporter le processus commun de la
chaîne logistique. De ce fait, nous avons montré les démarches
d’application de solutions à chaque étape de la feuille de route allant de
l’externalisation des processus locaux jusqu’à l’orchestration de
Workflow global.
Le principe de l’architecture cadre est basé sur l’intégration des
activités des partenaires de la chaîne logistique. Cela peut être traduit
par offrir des facilités permettant l’échange de l’information et la
coordination de processus métiers distribué dans un processus commun.
Une démarche essentielle pour l’application de la feuille de route est
l’externalisation des processus internes par le biais de services Web. Ce
faisant, les entreprises peuvent contrôler l’accès à laure systèmes
d’information locaux par les autres entités de business. La composition
du processus commun à partir des services Web résultant nécessite une
Mayyad JABER 195
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
organisation flexible du Workflow global afin de permettre l’intégration
des Workflows hétérogènes. A cet effet, nous avons introduit le
médiateur comme un moyen d’interconnexion entre les Workflows ad
hoc et les Workflows formels.
L’exécution du processus commun est réalisée par l’échange
des messages entre les services participants. Les messages échangés sont
issus des systèmes d’information patrimoniaux hétérogènes des
partenaires. Cela impose un traitement spécifique pour garantir
l’interopérabilité au niveau de données. A cette fin, nous avons proposé
une solution à base des objets métier qui peuvent être sauvegardés dans
un référentiel accessible par tous les partenaires de la chaîne logistique
afin d’implémenter les services Web nécessaires pour participer au
processus commun.
Les services Web résultants encapsulent des ressources
appartiennent aux partenaires peuvent être accédées, réservées,
consumées ou libérées par les différentes entités de business de manière
concourante. Cela peut conduire à des états d’interblocage pour les
ressources dans le cas où des pannes surviennent dans le système. A cet
effet, nous avons proposé un mécanisme de gestion de ressources
distribuées afin d’éviter les états d’interblocage. Ensuite, et afin
supporter l’exécution distribuée du processus commun, nous avons
introduit la notion du processus commun transactionnel. Il s’agit
d’intégrer un système de gestion de transactions distribuées dédié pour
le traitement des exceptions issues des pannes liées aux matériels ou aux
logiciels. Nous avons présenté en détail la hiérarchie du système avec
les rôles de chaque composant par le biais des diagrammes détaillés de
transition d’état.
Afin de montrer comment intégrer la solution proposée pour la
gestion de transactions distribuées, nous avons implémenté un prototype
du processus commun transactionnel. Nous avons défini une architecture
de plate-forme de développement permettant la construction du
processus commun. Plus particulièrement, nous avons mis l’accent sur la
mise en œuvre du processus commun transactionnel par
l’implémentation des gestionnaires de transactions distribuées.
Mayyad JABER 196
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Perspectives
Dans ce travail, nous avons abordé les problématiques liées à la mise en
place du système d’information distribué pour la gestion de la chaîne
logistique. Nous avons présenté une vision du processus commun
interentreprises qui permet de renforcer la collaboration entre les
partenaires de la chaîne logistique. Nos propositions offrent des
solutions dédiées pour interconnecter des entités de business au sein de
la chaîne logistique, mais évidemment, il reste comme tout travail de
recherche des perspectives pour amener de futurs projets de recherche :
L’aspect de sécurité du processus commun est un axe primordial.
Une politique de sécurité doit être mise en place afin de protéger
les systèmes d’information rendues ouverts par le biais de services
Web.
Afin de renforcer l’interopérabilité au niveau de données nous
avons proposé une solution à base des objets métier. Cette solution
peut être perfectionnée par la définition d’une ontologie pour
décrier les objets métiers qui seront sauvegardés dans un référentiel
commun.
Au niveau de gestion de transaction, nous avons proposé un
système avec une hiérarchie basée sur des gestionnaires de
transactions distribués. Au cours de l’exécution du processus
commun, ces gestionnaires entrent dans des états d’attente pour des
réponses des autres composants du processus transactionnel. Afin
de garantir la flexibilité et éviter les interblocages, nous avons
proposé d’utiliser les triggers de dépassement de délai pour
permettre aux gestionnaires de procéder à l’exécution de l’étape
suivante dans les cas échéants. Une étude doit être menée afin de
déterminer les délais d’attente initiaux. En suite, ces délais peuvent
être mis à jour dans la phase de reingénierie.
En vue d’expérimenter les solutions proposées, une plate-forme de
simulation est indispensable. Cette plate-forme doit permettre la
simulation des activités des entités de business dans des conditions qui
sont les plus proches des conditions du domaine de B2B.
Mayyad JABER 197
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Bibliographie
Aalst, W. M. P. v. d., 2000, Process-oriented architectures for electronic commerce and
interorganizational workflow, Information Systems, 24(8), pp. 639-671.
Aalst, W. M. P. v. d., 2002a, Inheritance of inter-organizational workflows to enable business to
business E-commerce, Electronic commerce research, 2, pp. 195-231.
Aalst, W. M. P. v. d., 2002b, Making Work Flow: On the Application of Petri Nets to Business
Process Management, Lecture Notes in Computer Science, (2360), pp. 1–22.
Ahn, H. and Lee, H., 2004, An Agent-Based Dynamic Information Network for Supply Chain
Management, BT Technology Journal, 22(2), pp. 18-27.
Albani, A., Keiblinger, A., Turowski, K. and Winnewisser, C., 2003, Identification and Modelling
of Web Services for Inter-enterprise Collaboration Exemplified for the Domain of
Strategic Supply Chain Development, In On The Move to Meaningful Internet Systems:
Confederated International Conferences CoopIS, DOA, and ODBASE. Vol. LNCS 2888
(Eds, Meersmann, R., Tari, Z. and Schmidt, D. C.). Springer Verlag, Italy, pp . 74-92.
Ali, L., Jaber, M., Chaari, S. and Biennier, F., 2007, Context-aware infrastructure to support
distributed industrial services, In ETFA’07: 12th IEEE Conference on Emerging
Technologies and Factory Automation. 25-28 September, Patras, Greece.
Arent, J., 2000, Transforming Software Organizations with the Capability Maturity Model,
Lecture Notes in Computer Science, (1840), pp. 103-114.
Baader, F., Calvanese, D., McGuinness, D., Nardi, D. and Patel, S., 2003, The Description Logic
Handbook. Theory, Implementation and Applications, Cambridge : Cambridge Press.
Bakos, Y., 1998, The Emerging Role of Electronic Marketplaces on the Internet, Communications
of the ACM, 41(8), pp. 35-42.
Barnett, M. W. and Miller, C. J., 2000, Analysis of the Virtual Enterpr ise Using Distributed
Supply Chain Modeling and Simulation: An Application of e-SCOR, In Proceedings of
the 2000 Winter Simulation Conference. (Eds, Joines, J. A., Barton, R. R., Kang, K. and
Fishwick, P. A.). Insitute of Electrical and Electronics Engineers, Piscataway, New
Jersey, pp. 352-355.
BEA, 2006. Service-oriented Architecture. "http://dev2dev.bea.com/soa/" (consulté le
13.05.2007).
Beamon, L. and Benita, M., 1998, Supply chain design and analysis: models and methods,
International Journal of Production Economics, (55), pp. 281-294.
Beecham, S., Hall, T. and Rainer, A., 2005, Defining a Requirements Process Improvement
Model, Software Quality Journal, 13(3), pp. 247-279.
Bilotta, J. G. and McGrew, J. F., 1998, A Guttman Scaling of CMM Level 2 Practices:
Investigating the Implementation Sequences Underlying Software Engineering Maturity,
Empirical Software Engineering, 3(2), pp. 159-177.
Mayyad JABER 198
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R. and Selby, R., 1995, Cost models
for future software life cycle processes: COCOMO 2.0, Annals of Software Engineering,
1(1), pp. 57-94.
Bordeaux, L., Salaun, G., Berardi, D. and Mecella, M., 2004, When are two web services
Compatible, In The 5th conference on Technologies for E-Services, Toronto, Canada, pp.
15-28.
Borges, M. R. S., Vincent, A. F., Penadas, M. C. and Araujo, R. M., 2005, Introducing Business
Process into Legacy Information Systems, Lecture Notes in Computer Science, 3649, pp.
452-457.
Bos, E. and Vriens, C., 2004, An Agile CMM, Lecture Notes in Computer Science, (3134), pp.
129-138.
BPMI, 2007 The Business Process Management Initiative. "http://www.bpmi.org/" (consulté le
15.04.2008).
Bremer, C. F., Mundim, A. P. F., Michilini, F. V. S., Siqueira, J. E. M. and Ortega, L. M., 1999,
A Brazilian case of VE coordination, In Infrastructures for Virtual Enterprises. (Eds,
Camarinha-Matos, L. M. and Afsarmanesh, H.). Kluwer Academic Publishers, Boston,
pp. 377-386.
Bussler, C., 2001, B2B Protocol Standards and their Role in Semantic B2B Integration Engines,
IEEE Bulletin of the TC on Data Engineering, 24(1), pp. 3-11.
Bussler, C., 2002, The application of workflow technology in semantic B2B integration,
Distributed and parallel databases, 12, pp. 163-191.
Cardoso, J., Sheth, A., Miller, J., Arnold, J. and Kochut, K., 2004, Quality of service for
workflows and web service processes, Journal of Web Semantics, 1(3), pp. 281-308.
Casey, V. and Richardson, I., 2002, A Practical Application of the IDEAL Model, Lecture Notes
in Computer Science, (2559), pp. 172-184.
Cha, J.-E., Kim, C.-H. and Yang, Y.-J., 2004, Architecture Based Software Reengineering
Approach for Transforming from Legacy System to Component Based System through
Applying Design Patterns, Lecture Notes in Computer Science, (3026), pp. 266-278.
Chaari, S., 2008. Interconnexion des processus Interentreprises : une approche orientée services.
Thèse. Villeurbanne : INSA de Lyon.
Chaari, S., Biennier, F., Favrel, J. and Benamar, C., 2007, Towards service oriented enterprise
based on business component identification, In IESA'07 proceedings 3rd International
Conference on Interoperability for Enterprise Software and Applications. Mrach 28-30,
Madeira Portugal, pp. 495-506.
Chandrashekar, A. and Schary, P., 2002 In Managing virtual web organizations in the 21st
century: issues and challenges. IGI Publishing, Hershey, PA, USA, pp. 90-106.
Chatterjee, D. and Ravichandran, T., 2004, Beyond exchange models: Understanding the structure
of B2B information systems, Information Systems and E-Business Management, 2(2 - 3),
pp. 169-186.
Cheng, F.-T., Chang, C.-F. and Wu, S.-L., 2004, Development of holonic manufacturing
execution systems, Journal of Intelligent Manufacturing, 15(2), pp. 253-267.
Chiu, D. K. W., Cheung, S. C., Till, S., Karlapalem, K., Li, Q. and Kafeza, E., 2004, Workflow
View Driven Cross-Organizational Interoperability in a Web Service Environment,
Information Technology and Management, 5(3 - 4), pp. 221-250.
Mayyad JABER 199
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N. and Weerawarana, S., 2002,
Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI, IEEE
Internet Computing, 6, pp. 86-93.
Curley, M., 2006, IT Innovation: A New Era, Lecture Notes in Computer Science, (3991), pp. 4-6.
Damian, D., Zowghi, D., Vaidyanathasamy, L. and Pal, Y., 2004, An Industrial Case Study of
Immediate Benefits of Requirements Engineering Process Improvement at the Australian
Center for Unisys Software, Empirical Software Engineering, 9(1 - 2), pp. 45-75.
Davenport, T. and Short, J., 1990, The New Industrial Engineering: Information Technology and
Business Process Redesign, Sloan Management Review, 31(4), pp. 11-27.
Davidsson, P. and Johansson, S., 2003, Evaluating Mult i-agent System Architectures: A Case
Study Concerning Dynamic Resource Allocation, In Engineering Societies in the Agents
World III: Third International Workshop, ESAW 2002. September 16-17, 2002, Madrid,
Spain, pp. 170-183.
Davis, A., 2005, Keynote: Just Enough Requirements Management for Web Engineering, Lecture
Notes in Computer Science, (3579), pp. 1-2.
DiCaterino, A., Larsen, K., Tang, M. and Wang, W., 1997. An Introduction to Workflow
Management Sysytems. Center for Technology in Government, University at Albany /
SUNY.
"http://www.ctg.albany.edu/publications/reports/workflow_mgmt/workflow_mgmt.pdf"
Dittrich, K. and Tombros, D., 1999, Workflow Management for the Virtual Enterprise Process, In
IPTW'99: International Process Technology Workshop. January, Villard de Lans, France.
Dooley, K., Subra, A. and Anderson, J., 2001, Maturity and its impact on new product
development project performance, Research in Engineering Design, 13(1), pp. 23-29.
Dumke, R. R. and Grigoleit, H., 1997, Efficiency of CAMEtools in software quality assurance,
Software Quality Journal, 6(2), pp. 157-169.
El-Emam, K., Goldenson, D., McCurley, J. and Herbsleb, J., 2001, Modelling the Likelihood of
Software Process Improvement: An Exploratory Study, Empirical Software Engineering,
6(3), pp. 207-229.
Fournier-Morel, X., Grojean, P., Plouin, G. and Rognon, C., 2006, SOA, Le guide de l'architecte.
Paris : DUNOD.
Fu, S., Chung, J.-Y. and Dietrich, W., 1999 IBM. A Practical Approach to Web-Based Internet
EDI. "http://www.research.ibm.com/iac/papers/icdcsws99.pdf" .
Geib, J.-M. and Merle, P., 2000, CORBA : des concepts à la pratique, Techniques de l'ingénieur.
Informatique, HB2(H2758), pp. 1-30.
Ginsburg, M. and Duliba, K., 1997, Enterprise-Level Groupware Choices: Evaluating Lotus Notes
and Intranet-Based Solutions, Computer Supported Cooperative Work (CSCW), 6(2 - 3),
pp. 201-225.
Girard, D. and Crusson, T., 2001. Livre blanc : XML pour l'entreprise. Improve.
"http://www.application-servers.com/livresblancs" (consulté le 12.09.2007).
Haake, J. and Wang, W., 1997, Flexible support for business processes : extending cooperative
hypermedia with process support, ACM Press, november 1997, Phoenix, pp. 341-350.
Mayyad JABER 200
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Hollingsworth, D., 1995. The Workflow Reference Model. The Workflow Management Coalition
Specification, Technical Report TC00-1003. Hampshire, UK. "http://www.aifb.uni-
karlsruhe.de/Lehrangebot/Winter2000-01/Wfm/referenzm.pdf" (consulté le 15.01.2005).
Hsieh, K.-L. and Tong, L.-I., 2006, Manufacturing performance evaluation for IC products, The
International Journal of Advanced Manufacturing Technology, 28(5 - 6), pp. 610-617.
Hwang, S.-M. and Yeom, H.-G., 2006, Metrics Design for Software Process Assessment Based on
ISO/IEC 15504, Lecture Notes in Computer Science, (3983), pp. 909-916.
Hwang, Y.-D., 2006, The practices of integrating manufacturing execution systems and Six
Sigma methodology, The International Journal of Advanced Manufacturing Technology,
31(1), pp. 145-154.
IST , 2005. Enterprise Interoperability: Research Roadmap. V. 1.0. Information Society
Technologies 74 Pages.
"ftp://ftp.cordis.lu/pub/ist/docs/directorate_d/ebusiness/20051221_roadmap_v10.pdf"
(consulté le 25.02.2006).
ITU-T, 1999. Z100: Specification and description language (SDL). "http://www.itu.int/ITU-
T/studygroups/com10/languages/Z.100_1199.pdf" (consulté le 18.04.2006).
Jaber, M., 2004. Architecture de système d'information distribué pour la gestion de l'entreprise
virtuelle. Mémoire du Stage de DEA. Villeurbanne : Laboratoire d'Informatique pour
l'Entreprise et les Systèmes de Production, INSA de Lyon. Lyon.
Jaber, M., Badr, Y. and Biennier, F., 2006a, Building Global Workflow from the Scratch: An
Approach Based On Integration of Heterogenic Workflows by Mediators, In APMS’06:
The international conference on Advances in Production Management Systems. 18-20
September, Wroclaw, Poland.
Jaber, M., Badr, Y. and Biennier, F., 2006b, Distributed Information System for the Supply Chain
Integration, In ICTTA’06: 2nd IEEE International Conference on Information &
Communication Technologies from Theory to Applications, Volume: 1, page(s): 227-
232. ISBN: 0-7803-9521-2. 24-28 April, Damascus, Syria.
Jaber, M., Badr, Y. and Biennier, F., 2006c, Service Oriented Organization for Cross Enterprise
Processes and Distributed Transactions, In INCOM’06: 12th IFAC International
Symposium on Information Control Problems in Manufacturing. 17-19 Mai, Saint
Etienne, France.
Jaber, M., Badr, Y., Biennier, F. and Favrel, J., 2005, An Integrated Open System To Support
Cyber-Partnering, In IFIP 5.7: The international conference on Advances in Production
Management Systems. September 18-21, Rockville, MD, USA.
JBoss, 2005. Extending JBossIDE: An introduction to extending eclipse and JBossIDE, V1.0
WIP. "http://docs.jboss.org/jbosside/cookbook/build/en/pdf/JBossIDE-Cookbook.pdf"
(consulté le 12.04.2008).
JBoss, 2006. JBoss jBPM - Workflow in Java: jBPM jPDL User Guide, V. 3.2.3. "http://docs.
jboss.com/jbpm/v3.2/userguide/pdf/jbpm-jpdl.pdf" (consulté le 02.06.2008).
JBoss, 2007a. JBoss jBPM :WS-BPEL Runtime User Guide, V. 1.1. "http://docs.jboss.com/jbpm/
bpel/v1.1/userguide/" (consulté le 12.07.2008).
JBoss, 2007b. JBoss Server Manager Reference Guide. "http://docs.jboss.org/tools/2.0.0.GA/as/
en/pdf/server_manager_guide.pdf" (consulté le 15.06.2008).
Mayyad JABER 201
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
JBoss, 2007c. JBoss Transactions 4.2.3: Administration Guide. "http://www.jboss.org/file -
access/default/members/jbosstm/freezone/docs/4.2.3/manuals/pdf/jts/AdministrationGuid
e.pdf" (consulté le 14.05.2008).
Kardasis, P. and Loucopoulos, P., 1998, Aligning Legacy Information Systems to Business
Processes, Lecture Notes in Computer Science, (1413), pp. 25-39.
Katzy, R. B. and Schuh, G., 1998, The virtual enterprise, In Handbook of Life Cycle Engineering:
Concepts, Methods and Tools. (Eds, Molina, A., Sanchez, J. M. and Kusiak, A.. Kluwer
Academic Publishers, Dordrecht.
Khoo, L. P. and Yin, X. F., 2003, An extended graph-based virtual clustering-enhanced approach
to supply chain optimisation, The International Journal of Advanced Manufacturing
Technology, 22(11 - 12), pp. 836-847.
Koca, G., 2000. Développement du prototype Calife. CALIFE/Sous-Projet 1/Fourniture 2/V1.0.
LORIA. "http://www.loria.fr/projets/calife/WebCalifePublic/FOURNITURES/F1.2.doc"
(consulté le 22.10.2006).
Krafzig, D., Banke, K. and Slama, D., 2004, Enterprise SOA: Service-Oriented Architecture Best
Practices. Indianapolis (IN) : Prentice Hall.
Kwak, M., Han, D. and Shim, J., 2002, A framework supporting dynamic workflow interoperation
and enterprise application integration, 35th Annual Hawaii International Conference on
System Sciences, Hawaii, USA, pp. 3766- 3775.
Lambert, D. M., Cooper, M. C. and Pagh, J. D., 1998, Supply chain management: Implementation
issues and research opportunities, The International Journal of Logistics Management,
9(2), pp. 1-19.
Lazcano, A., Alonso, G., Schuldt, H. and Schuler, C., 2000, The WISE Approach to Electronic
Commerce, Computer Systems Science & Engineering, 15(5), pp. 345-357.
Lebsanft, K., 2001, Process Improvement in Turbulent Times - Is CMM Still an Answer ?,
Lecture Notes in Computer Science, (2188), pp. 78-85.
Lee, E.-s., Lee, K. W., Kim, T.-h. and Jung, I.-H., 2004a, Introduction and Evaluation of
Development System Security Process of ISO/IEC TR 15504, Lecture Notes in Computer
Science, (3043), pp. 451-460.
Lee, H.-k., Shim, J.-s., Lee, S. and Kim, J.-b., 2004b, A Relationship of Configuration
Management Requirements between KISEC and ISO/IEC 15408, Lecture Notes in
Computer Science, (3046), pp. 725-734.
Lee, W. and Kaiser, G. E., 1999, Interfacing Oz with the PCTE OMS: A Case Study of
Integrating a Legacy System with a Standard Object Management System, Journal of
Systems Integration, 9(4), pp. 329-358.
Li, H., Huang, C., Su, S. Y. W. and Higdon, B., 2002, Design and Implementation of Business
Objects for Automated Business Negotiations, Group Decision and Negotiation, 11(1),
pp. 23-44.
Lummus, R. R. and Vokurka, R. J., 1999, Defining supply chain management: a historical
perspective and practical guidelines, Industrial Management & Data Systems, 99(1), pp.
11 - 17.
Mackie, C., 1997, Process excellence and capability determination, BT Technology Journal,
15(3), pp. 130-139.
Mayyad JABER 202
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Mammar, A., Ramel, S., Gregoire, B., Schmitt, M. and Guelfi, N., 2005, Efficient: A Toolset for
Building Trusted B2B Transactions, Lecture Notes in Computer Science, (3520), pp. 430-
445.
Mcguire, E. G., 1996, Factors affecting the quality of software project management: an empirical
study based on the Capability Maturity Model, Software Quality Journal, 5(4), pp. 305-
317.
McLaren, T. S., Head, M. M. and Yuan, Y., 2004, Supply chain management information systems
capabilities. An exploratory study of electronics manufacturers, Information Systems and
E-Business Management, 2(2 - 3), pp. 207-222.
Mecella, M., Pernici, B., Rossi, M. and Testi, A., 2001, A Repository of Workflow Components
for Cooperative e-Applications, In IFIP TC8 Working Conference on E-Commerce/E-
Business. BICE Press, Salzburg, Austria, pp. 73-92.
Medjahed, B. and Bouguettaya, A., 2005, A multilevel composability model for semantic web
services, IEEE Transactions on Knowledge and Data Engineering, 17(7), pp. 954-968.
Mills, J. A., 1993, Large scale interoperability and distributed transaction processing, Journal of
Systems Integration (Historical Archive), 3(3 - 4), pp. 351-369.
Milo, T., Abiteboul, S., Amann, B., Benjelloun, O. and Ngoc, F. D., 2005, Exchanging
intensional XML data, ACM Trans. Database Syst., 30(1), pp. 1-40.
Muth, P., 1997, Application Specific Transaction Management in Multidatabase Systems,
Distributed and Parallel Databases, 5(4), pp. 357-403.
Naumenko, A., Wegmann, A., Genilloud, G. and Frank, W. F., 2001, Proposal for a formal
foundation of RM-ODP concepts, In ICEIS 2001, WOODPECKER. (Eds, Cordeiro, J. and
Kilov, H.). July, Setúbal, Portugal.
Niazi, M., Wilson, D., Zowghi, D. and Wong, B., 2004, A Model for the Implementation of
Software Process Improvement: An Empirical Study, Lecture Notes in Computer Science,
(3009), pp. 1-16.
Oasis, 2001. Business Process and Business Information analysis overview v1.0. "http://www.
ebxml.org/specs/bpOVER.pdf" (consulté le 07.11.2005).
OASIS, 2005: Organization for the Advancement of Structured Information Standards. "http://
www.oasis-open.org/cover/siteIndex.html" (consulté le 15.11.2006).
Oba, M. and Komoda, N., 2001, Multiple Type Workflow Model for Enterprise Application
Integration, In HICSS-34: 34th Hawaii International Conference on System Sciences.
January 3-6, Hawaii, USA.
OMG, 2001. Object Constraint Language Specification (in UML 1.4). "http://www.omg.org/"
(consulté le 22.04.2006).
OMG, 2005: Object Management Group. "http://www.omg.org/" (consulté le 17.09.2006).
Papazoglou, M. P., 2003, Web Services and Business Transactions, World Wide Web, 6(1), pp.
49-91.
Papazoglou, M. P. and Heuvel, W.-J. v. d., 2000, Configurable Business Objects for Building
Evolving Enterprise Models and Applications, In Business Process Management, Models,
Techniques, and Empirical Studies. Berlin : Ed, Springer-Verlag. pp. 328-344.
Mayyad JABER 203
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Parzinger, M. J., Nath, R. and Lemons, M. A., 2001, Examining the Effect of the
Transformational Leader on Software Quality, Software Quality Journal, 9(4), pp. 253-
267.
Paulk, M. C., 1993, Comparing ISO 9001 and the Capability Maturity Model for Software,
Software Quality Journal, 2(4), pp. 245-256.
Polo, M., Piattini, M., Ruiz, F. and Jimenez, M., 2001, Assessment of Maintenance Maturity in IT
Departments of Public Entities: Two Case Studies, Lecture Notes in Computer Science,
(2188), pp. 86.
Prego, M., 2003, Reuse Based Software Factory, Lecture Notes in Computer Science, (2765), pp.
256-273.
Rabaey, M., Vandyck, E. and Tromp, H., 2003, Business Intelligent Agents for Enterprise
Application Integration : the link between Business Process Management and Web
Services, In ICSSEA'2003: 16th International Conference on Software & Systems
Engineering and their Applications December 2-4, Paris, France.
Raymond, K., 1995, Reference Model of Open Distributed Processing (RM-ODP): Introduction,
In International Conference on Open Distributed Processing. 20-24 Feb, Brisbane,
Australia.
Ren, Y., Wu, Q., Jia, Y., Guan, J. and Han, W., 2004, Transactional Business Coordination and
Failure Recovery for Web Services Composition, Lecture Notes in Computer Science,
(3251), pp. 26-33.
RosettaNet, 2006. "http://www.rosettanet.org/" (consulté le 12.05.2007).
Ruiz, M., Ramos, I. and Toro, M., 2002, A Dynamic Integrated Framework for Software Process
Improvement, Software Quality Journal, 10(2), pp. 181-194.
Sadiq, W. and Orlowska, M., 1999, Capturing Process Requirements of Workflow Based
Information Systems, In 3rd International Conference on Business Information Systems
BIS 99. Springer-Verlag, April 14-16, Poznan, Poland, pp. 195-209.
Saiedian, H. and McClanahan, L., 1996, Frameworks for quality software process: SEI Capability
Maturity Model versus ISO 9000, Software Quality Journal, 5(1), pp. 1-23.
SCC, 2008 Supply-Chain Council. The Supply-Chain Operations Reference-model, SCOR
Overview V. 9.0. "http://www.supply-chain.org/galleries/public-gallery/SCOR 9.0
Overvie Booklet.pdf" (consulté le 11.10.2008).
Scheer, A.-W., 1998, ARIS - Business Process Frameworks, Berlin : Springer.
Scheer, A.-W. and Nuttgens, M., 2000, ARIS Architecture and Reference Models for Business
Process Management, in Business Process Management, Lecture Notes in Computer
Science, (1806).
Scuckmann C., Kirchner L., Schümmer J. and Haake J.M., 1996, Designing object -oriented
synchronous groupware with COAST, In The 1996 ACM conference on Computer
supported cooperative work ACM Press, 16-20 november 1996, Boston, Massachusetts,
United States, pp. 30-38.
ShaikhAli, A., Rana, O. F., Al-Ali, R. and Walker, D. W., 2003, UDDIe: An Extended Registry
for Web Services, In Proceedings of the 2003 Symposium on Applications and the
Internet Workshops (SAINT'03 Workshops). IEEE Computer Society, Orlando FL, USA,
pp. 85-90.
Mayyad JABER 204
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Shen, M. and Liu, D. R., 2001, Coordinating Interorganizational Workflows Based on Process -
Views, Lecture Notes in Computer Science, (2113), pp. 274-283.
SOAP 2007: Simple Object Access Protocol. " http://www.w3.org/TR/SOAP/" (consulté le
07.09.2008).
Stanford, 1997 The Stanford Rapide Project. The X/Open Distributed Transaction Processing
(DTP) Industry Standard. "http://pavg.stanford.edu/rapide/examples/xopen/" (consulté le
14.09.2006).
Stephens, S., 2001, Supply Chain Operations Reference Model Version 5.0: A New Tool to
Improve Supply Chain Efficiency and Achieve Best Practice, Information Systems
Frontiers, 3(4), pp. 471-476.
Taipale, V. and Taramaa, J., 2005, Process Improvement Solution for Co-design in Radio Base
Station DSP SW, Lecture Notes in Computer Science, (3547), pp. 16-28.
Tambag, Y. and Cosar, A., 2003, ebIOP: An ebXML Compliant B2B Interoperability Platform, In
EC-Web2003: 4th International Conference on E-Commerce and Web Technologies 1-5
September, Prague, Czech Republic, pp. 155 -164.
Tan, Y. H. and Thoen, W., 2002, Using Event Semantics for Modeling Contracts, In The 35th
Hawaii International Conference on System Sciences. Hawaii, USA, pp. 2198-2206.
Tang, J., Fu, A. W. and Veijalainen, J., 2004, Supporting Dispute Handling in E -Commerce
Transactions, a Framework and Related Methodologies, Electronic Commerce Research,
4(4), pp. 393-413.
Taylor, D. A., 2004, Supply Chains: A Manager's Guide, Boston : Addison-Wesley.
Taylor, J., 2005, Achieving Decision Consistency Across the SOA-Based Enterprise Using
Business Rules Management Systems, Lecture Notes in Computer Science, (3806), pp.
750-761.
UDDI, 2007 Universal Description Discovery and Integration. "http://www.uddi.org/" (consulté
le 11.01.2008).
Vaishnavi, V. K. and Kuechler, W. L., 2005, Universal Enterprise Integration: Challenges of and
Approaches to Web-Enabled Virtual Organizations, Information Technology and
Management, 6(1), pp. 5-16.
Velden, M. J., Vreke, J., Wal, B. and Symons, A., 1996, Experiences with the capability maturity
model in a research environment, Software Quality Journal, 5(2), pp. 87-95.
Verwijmeren, M., 2004, Software component architecture in supply chain management,
Computers in Industry, 53(2), pp. 165-178.
Vinoski, S., 1997, CORBA: integrating diverse applications within distributed heterogeneous
environments, Communications Magazine, IEEE, 35(2), pp. 46-55.
Watson, G. H., 2002, Breakthrough in Delivering Software Quality: Capability Maturity Model
and Six Sigma, Lecture Notes in Computer Science, (2349), pp. 36.
Weber, B. and Wild, W., 2005, Towards the Agile Management of Business Processes, Lecture
Notes in Computer Science, (3782), pp. 409-419.
Weber, M., Illmann, T. and In, A. S., 1998, Webflow: Decentralized workflow management in the
world wide web, In the Intermational Conference on Applied Informatics (AI'98).
Februar23-25, Garmisch-Partenkirchen, Germany.
Mayyad JABER 205
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Webster, J., 1995, Networks of collaboration or conflict? Electric Data Interchange and Power in
the Supply Chain, Journal of Strategic Information Systems, (4), pp. 31-42.
WfMC, 2007 Workflow Management Coalition. "http://www.wfmc.org/" (consulté le
15.02.2008).
White, S. A. 2004 Business Process Trends. Introduction to BPMN. "http://www.bptrends.com/
publicationfiles/07-04 WP Intro to BPMN - White.pdf" (consulté le 12.03.2006).
Wohed, P., Aalst, W. M. P. v. d., Dumas, M. and Hofstede, A. H. M. t., 2003, Analysis of Web
Services Composition Languages: The Case of BPEL4WS, Lecture Notes in Computer
Science, (2813), pp. 200-215.
Wombacher, A. and Mahleko, B., 2002, Finding Trading Partners to Establish Ad-hoc Business
Processes, Lecture Notes in Computer Science, (2519), pp. 339-355.
X/Open, 1996. Distributed Transaction Processing: Reference Model, Version 3. X/Open
Company Limited. "http://www.opengroup.org/onlinepubs/009680699/toc.pdf" (consulté
le 11.05.2007).
Xu, P., Michailidis, G. and Devetsikiotis, M., 2006, Profit-oriented resource allocation using
online scheduling in flexible heterogeneous networks, Telecommunication Systems,
V31(2), pp. 289-303.
Yajaman, N., Brown, J., Subramaniam, S., John, T., Reddy, N. and Mason, A., 2003 MSDN. Web
Service Facade for Legacy Applications. "http://msdn.microsoft.com/library/" (consulté
le 12.03.2006).
Yan, Y., Maamar, Z. and Weiming Shen, W., 2001, Integration of Workflow and Agent
Technology for Business Process Management, In Proc. of CSCWD01. 12-14 July,
London, Ont., Canada, pp. 420-426.
Mayyad JABER 206
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
Annex A
A.1 Fichier WSDL du "factory"
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://DefaultNamespace"
xmlns:intf="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema elementFormDefault="qualified" targetNames-
pace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="creeRacine">
<complexType>
<sequence>
<element name="RacineID" type="xsd:string"/>
<element name="ServiceID" type="xsd:string"/>
<element name="listInf" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<complexType name="ArrayOf_xsd_anyType">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="item"
type="xsd:anyType"/>
</sequence>
</complexType>
<element name="creeRacineResponse">
<complexType/>
</element>
<element name="creeInferieur">
<complexType>
<sequence>
<element name="InferieurID" type="xsd:string"/>
<element name="ServiceID" type="xsd:string"/>
<element name="listGR" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<element name="creeInferieurResponse">
<complexType/>
</element>
<element name="creeSuperieur_Inferieur">
<complexType>
Mayyad JABER 207
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<sequence>
<element name="Superieur_InferieurID" type="xsd:string"/>
<element name="ServiceID" type="xsd:string"/>
<element name="SuperieurID" type="xsd:string"/>
<element name="listInf" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<element name="creeSuperieur_InferieurResponse">
<complexType/>
</element>
</schema>
</wsdl:types>
<wsdl:message name="creeSuperieur_InferieurRequest">
<wsdl:part element="impl:creeSuperieur_Inferieur"
name="parameters"/>
</wsdl:message>
<wsdl:message name="creeInferieurRequest">
<wsdl:part element="impl:creeInferieur" name="parameters"/>
</wsdl:message>
<wsdl:message name="creeRacineRequest">
<wsdl:part element="impl:creeRacine" name="parameters"/>
</wsdl:message>
<wsdl:message name="creeInferieurResponse">
<wsdl:part element="impl:creeInferieurResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="creeRacineResponse">
<wsdl:part element="impl:creeRacineResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="creeSuperieur_InferieurResponse">
<wsdl:part element="impl:creeSuperieur_InferieurResponse"
name="parameters"/>
</wsdl:message>
<wsdl:portType name="Factory">
<wsdl:operation name="creeRacine">
<wsdl:input message="impl:creeRacineRequest"
name="creeRacineRequest"/>
<wsdl:output message="impl:creeRacineResponse"
name="creeRacineResponse"/>
</wsdl:operation>
<wsdl:operation name="creeInferieur">
<wsdl:input message="impl:creeInferieurRequest"
name="creeInferieurRequest"/>
<wsdl:output message="impl:creeInferieurResponse"
name="creeInferieurResponse"/>
</wsdl:operation>
<wsdl:operation name="creeSuperieur_Inferieur">
<wsdl:input message="impl:creeSuperieur_InferieurRequest"
name="creeSuperieur_InferieurRequest"/>
<wsdl:output mes-
sage="impl:creeSuperieur_InferieurResponse"
name="creeSuperieur_InferieurResponse"/>
</wsdl:operation>
Mayyad JABER 208
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:portType>
<wsdl:binding name="FactorySoapBinding" type="impl:Factory">
<wsdlsoap:binding style="document" trans-
port="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="creeRacine">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="creeRacineRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="creeRacineResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="creeInferieur">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="creeInferieurRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="creeInferieurResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="creeSuperieur_Inferieur">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="creeSuperieur_InferieurRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="creeSuperieur_InferieurResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="FactoryService">
<wsdl:port binding="impl:FactorySoapBinding" name="Factory">
<wsdlsoap:address loca-
tion="http://localhost:8080/Transactions/services/Factory"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
A.2 Fichier WSDL du gestionnaire "racine"
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://DefaultNamespace"
xmlns:intf="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema elementFormDefault="qualified" targetNames-
pace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
Mayyad JABER 209
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<element name="attente_inferieurID">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_inferieurIDResponse">
<complexType/>
</element>
<element name="attente_WebService_Continue">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_WebService_ContinueResponse">
<complexType/>
</element>
<element name="AttenteInferieurPret">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="AttenteInferieurPretResponse">
<complexType/>
</element>
<element name="attente_WebService_Valide">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_WebService_ValideResponse">
<complexType/>
</element>
<element name="attente_Accompli">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_AccompliResponse">
<complexType/>
</element>
<element name="recevoirInferieur">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="infID" type="xsd:int"/>
Mayyad JABER 210
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</sequence>
</complexType>
</element>
<element name="recevoirInferieurResponse">
<complexType/>
</element>
<element name="recevoirWebService">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="serviceID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoirWebServiceResponse">
<complexType/>
</element>
<element name="enregister">
<complexType>
<sequence>
<element name="infID" type="xsd:int"/>
<element name="list" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<complexType name="ArrayOf_xsd_anyType">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="item"
type="xsd:anyType"/>
</sequence>
</complexType>
<element name="enregisterResponse">
<complexType/>
</element>
<element name="recevoirInsuffisant">
<complexType>
<sequence>
<element name="infID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoirInsuffisantResponse">
<complexType/>
</element>
<element name="envoyerGestionnaire">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="infID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="envoyerGestionnaireResponse">
<complexType/>
</element>
Mayyad JABER 211
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<element name="envoyerServiceWeb">
<complexType>
<sequence>
<element name="list" type="impl:ArrayOf_xsd_anyType"/>
<element name="serviceID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="envoyerServiceWebResponse">
<complexType/>
</element>
<element name="notifierWebService">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="ServiceID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="notifierWebServiceResponse">
<complexType/>
</element>
</schema>
</wsdl:types>
<wsdl:message name="envoyerGestionnaireRequest">
<wsdl:part element="impl:envoyerGestionnaire"
name="parameters"/>
</wsdl:message>
<wsdl:message name="enregisterRequest">
<wsdl:part element="impl:enregister" name="parameters"/>
</wsdl:message>
<wsdl:message name="AttenteInferieurPretRequest">
<wsdl:part element="impl:AttenteInferieurPret"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantRequest">
<wsdl:part element="impl:recevoirInsuffisant"
name="parameters"/>
</wsdl:message>
<wsdl:message name="AttenteInferieurPretResponse">
<wsdl:part element="impl:AttenteInferieurPretResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ContinueRequest">
<wsdl:part element="impl:attente_WebService_Continue"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantResponse">
<wsdl:part element="impl:recevoirInsuffisantResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliResponse">
<wsdl:part element="impl:attente_AccompliResponse"
name="parameters"/>
</wsdl:message>
Mayyad JABER 212
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:message name="notifierWebServiceRequest">
<wsdl:part element="impl:notifierWebService"
name="parameters"/>
</wsdl:message>
<wsdl:message name="enregisterResponse">
<wsdl:part element="impl:enregisterResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInferieurRequest">
<wsdl:part element="impl:recevoirInferieur"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_inferieurIDResponse">
<wsdl:part element="impl:attente_inferieurIDResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerGestionnaireResponse">
<wsdl:part element="impl:envoyerGestionnaireResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ContinueResponse">
<wsdl:part element="impl:attente_WebService_ContinueResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="notifierWebServiceResponse">
<wsdl:part element="impl:notifierWebServiceResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerServiceWebResponse">
<wsdl:part element="impl:envoyerServiceWebResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_inferieurIDRequest">
<wsdl:part element="impl:attente_inferieurID"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirWebServiceRequest">
<wsdl:part element="impl:recevoirWebService"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ValideRequest">
<wsdl:part element="impl:attente_WebService_Valide"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInferieurResponse">
<wsdl:part element="impl:recevoirInferieurResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliRequest">
<wsdl:part element="impl:attente_Accompli"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirWebServiceResponse">
<wsdl:part element="impl:recevoirWebServiceResponse"
name="parameters"/>
Mayyad JABER 213
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:message>
<wsdl:message name="attente_WebService_ValideResponse">
<wsdl:part element="impl:attente_WebService_ValideResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerServiceWebRequest">
<wsdl:part element="impl:envoyerServiceWeb"
name="parameters"/>
</wsdl:message>
<wsdl:portType name="Racine">
<wsdl:operation name="attente_inferieurID">
<wsdl:input message="impl:attente_inferieurIDRequest"
name="attente_inferieurIDRequest"/>
<wsdl:output message="impl:attente_inferieurIDResponse"
name="attente_inferieurIDResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Continue">
<wsdl:input mes-
sage="impl:attente_WebService_ContinueRequest"
name="attente_WebService_ContinueRequest"/>
<wsdl:output mes-
sage="impl:attente_WebService_ContinueResponse"
name="attente_WebService_ContinueResponse"/>
</wsdl:operation>
<wsdl:operation name="AttenteInferieurPret">
<wsdl:input message="impl:AttenteInferieurPretRequest"
name="AttenteInferieurPretRequest"/>
<wsdl:output message="impl:AttenteInferieurPretResponse"
name="AttenteInferieurPretResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Valide">
<wsdl:input mes-
sage="impl:attente_WebService_ValideRequest"
name="attente_WebService_ValideRequest"/>
<wsdl:output mes-
sage="impl:attente_WebService_ValideResponse"
name="attente_WebService_ValideResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdl:input message="impl:attente_AccompliRequest"
name="attente_AccompliRequest"/>
<wsdl:output message="impl:attente_AccompliResponse"
name="attente_AccompliResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirInferieur">
<wsdl:input message="impl:recevoirInferieurRequest"
name="recevoirInferieurRequest"/>
<wsdl:output message="impl:recevoirInferieurResponse"
name="recevoirInferieurResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirWebService">
<wsdl:input message="impl:recevoirWebServiceRequest"
name="recevoirWebServiceRequest"/>
<wsdl:output message="impl:recevoirWebServiceResponse"
name="recevoirWebServiceResponse"/>
Mayyad JABER 214
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:operation>
<wsdl:operation name="enregister">
<wsdl:input message="impl:enregisterRequest"
name="enregisterRequest"/>
<wsdl:output message="impl:enregisterResponse"
name="enregisterResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirInsuffisant">
<wsdl:input message="impl:recevoirInsuffisantRequest"
name="recevoirInsuffisantRequest"/>
<wsdl:output message="impl:recevoirInsuffisantResponse"
name="recevoirInsuffisantResponse"/>
</wsdl:operation>
<wsdl:operation name="envoyerGestionnaire">
<wsdl:input message="impl:envoyerGestionnaireRequest"
name="envoyerGestionnaireRequest"/>
<wsdl:output message="impl:envoyerGestionnaireResponse"
name="envoyerGestionnaireResponse"/>
</wsdl:operation>
<wsdl:operation name="envoyerServiceWeb">
<wsdl:input message="impl:envoyerServiceWebRequest"
name="envoyerServiceWebRequest"/>
<wsdl:output message="impl:envoyerServiceWebResponse"
name="envoyerServiceWebResponse"/>
</wsdl:operation>
<wsdl:operation name="notifierWebService">
<wsdl:input message="impl:notifierWebServiceRequest"
name="notifierWebServiceRequest"/>
<wsdl:output message="impl:notifierWebServiceResponse"
name="notifierWebServiceResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RacineSoapBinding" type="impl:Racine">
<wsdlsoap:binding style="document" trans-
port="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="attente_inferieurID">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_inferieurIDRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_inferieurIDResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Continue">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_WebService_ContinueRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_WebService_ContinueResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="AttenteInferieurPret">
<wsdlsoap:operation soapAction=""/>
Mayyad JABER 215
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:input name="AttenteInferieurPretRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="AttenteInferieurPretResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Valide">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_WebService_ValideRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_WebService_ValideResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_AccompliRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_AccompliResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirInferieur">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirInferieurRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirInferieurResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirWebService">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirWebServiceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirWebServiceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="enregister">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="enregisterRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="enregisterResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirInsuffisant">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirInsuffisantRequest">
Mayyad JABER 216
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirInsuffisantResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="envoyerGestionnaire">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="envoyerGestionnaireRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="envoyerGestionnaireResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="envoyerServiceWeb">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="envoyerServiceWebRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="envoyerServiceWebResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="notifierWebService">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="notifierWebServiceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="notifierWebServiceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="RacineService">
<wsdl:port binding="impl:RacineSoapBinding" name="Racine">
<wsdlsoap:address loca-
tion="http://localhost:8080/Transactions/services/Racine"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
A.3 Fichier WSDL du gestionnaire "inférieur"
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://DefaultNamespace"
xmlns:intf="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
Mayyad JABER 217
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<schema elementFormDefault="qualified" targetNames-
pace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="recevoirInsuffisant">
<complexType>
<sequence>
<element name="Gr_ID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoirInsuffisantResponse">
<complexType/>
</element>
<element name="attente_enregistre">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_enregistreResponse">
<complexType/>
</element>
<element name="attente_prepare">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_prepareResponse">
<complexType/>
</element>
<element name="attente_Superieur_Valide">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_Superieur_ValideResponse">
<complexType/>
</element>
<element name="attente_Accompli">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_AccompliResponse">
<complexType/>
</element>
<element name="attente_Termine">
<complexType>
Mayyad JABER 218
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_TermineResponse">
<complexType/>
</element>
<element name="enregistre">
<complexType>
<sequence>
<element name="GR_ID" type="xsd:int"/>
<element name="list" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<complexType name="ArrayOf_xsd_anyType">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="item"
type="xsd:anyType"/>
</sequence>
</complexType>
<element name="enregistreResponse">
<complexType/>
</element>
<element name="attente_GR_Pret">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_GR_PretResponse">
<complexType/>
</element>
<element name="recevoir_GR">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="GR_ID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoir_GRResponse">
<complexType/>
</element>
<element name="envoyer_GR">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="GR_ID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="envoyer_GRResponse">
Mayyad JABER 219
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<complexType/>
</element>
<element name="notifierSuperieur">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="SuperieurID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="notifierSuperieurResponse">
<complexType/>
</element>
</schema>
</wsdl:types>
<wsdl:message name="envoyer_GRResponse">
<wsdl:part element="impl:envoyer_GRResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantRequest">
<wsdl:part element="impl:recevoirInsuffisant"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantResponse">
<wsdl:part element="impl:recevoirInsuffisantResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliResponse">
<wsdl:part element="impl:attente_AccompliResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="notifierSuperieurResponse">
<wsdl:part element="impl:notifierSuperieurResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_enregistreRequest">
<wsdl:part element="impl:attente_enregistre"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoir_GRRequest">
<wsdl:part element="impl:recevoir_GR" name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_enregistreResponse">
<wsdl:part element="impl:attente_enregistreResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_Superieur_ValideResponse">
<wsdl:part element="impl:attente_Superieur_ValideResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_Superieur_ValideRequest">
<wsdl:part element="impl:attente_Superieur_Valide"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_TermineResponse">
Mayyad JABER 220
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:part element="impl:attente_TermineResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="enregistreResponse">
<wsdl:part element="impl:enregistreResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="notifierSuperieurRequest">
<wsdl:part element="impl:notifierSuperieur"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliRequest">
<wsdl:part element="impl:attente_Accompli"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_GR_PretRequest">
<wsdl:part element="impl:attente_GR_Pret" name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_prepareResponse">
<wsdl:part element="impl:attente_prepareResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyer_GRRequest">
<wsdl:part element="impl:envoyer_GR" name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_GR_PretResponse">
<wsdl:part element="impl:attente_GR_PretResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoir_GRResponse">
<wsdl:part element="impl:recevoir_GRResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_prepareRequest">
<wsdl:part element="impl:attente_prepare" name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_TermineRequest">
<wsdl:part element="impl:attente_Termine" name="parameters"/>
</wsdl:message>
<wsdl:message name="enregistreRequest">
<wsdl:part element="impl:enregistre" name="parameters"/>
</wsdl:message>
<wsdl:portType name="Inferieur">
<wsdl:operation name="recevoirInsuffisant">
<wsdl:input message="impl:recevoirInsuffisantRequest"
name="recevoirInsuffisantRequest"/>
<wsdl:output message="impl:recevoirInsuffisantResponse"
name="recevoirInsuffisantResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_enregistre">
<wsdl:input message="impl:attente_enregistreRequest"
name="attente_enregistreRequest"/>
<wsdl:output message="impl:attente_enregistreResponse"
name="attente_enregistreResponse"/>
</wsdl:operation>
Mayyad JABER 221
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:operation name="attente_prepare">
<wsdl:input message="impl:attente_prepareRequest"
name="attente_prepareRequest"/>
<wsdl:output message="impl:attente_prepareResponse"
name="attente_prepareResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Superieur_Valide">
<wsdl:input message="impl:attente_Superieur_ValideRequest"
name="attente_Superieur_ValideRequest"/>
<wsdl:output mes-
sage="impl:attente_Superieur_ValideResponse"
name="attente_Superieur_ValideResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdl:input message="impl:attente_AccompliRequest"
name="attente_AccompliRequest"/>
<wsdl:output message="impl:attente_AccompliResponse"
name="attente_AccompliResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Termine">
<wsdl:input message="impl:attente_TermineRequest"
name="attente_TermineRequest"/>
<wsdl:output message="impl:attente_TermineResponse"
name="attente_TermineResponse"/>
</wsdl:operation>
<wsdl:operation name="enregistre">
<wsdl:input message="impl:enregistreRequest"
name="enregistreRequest"/>
<wsdl:output message="impl:enregistreResponse"
name="enregistreResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_GR_Pret">
<wsdl:input message="impl:attente_GR_PretRequest"
name="attente_GR_PretRequest"/>
<wsdl:output message="impl:attente_GR_PretResponse"
name="attente_GR_PretResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoir_GR">
<wsdl:input message="impl:recevoir_GRRequest"
name="recevoir_GRRequest"/>
<wsdl:output message="impl:recevoir_GRResponse"
name="recevoir_GRResponse"/>
</wsdl:operation>
<wsdl:operation name="envoyer_GR">
<wsdl:input message="impl:envoyer_GRRequest"
name="envoyer_GRRequest"/>
<wsdl:output message="impl:envoyer_GRResponse"
name="envoyer_GRResponse"/>
</wsdl:operation>
<wsdl:operation name="notifierSuperieur">
<wsdl:input message="impl:notifierSuperieurRequest"
name="notifierSuperieurRequest"/>
<wsdl:output message="impl:notifierSuperieurResponse"
name="notifierSuperieurResponse"/>
</wsdl:operation>
Mayyad JABER 222
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:portType>
<wsdl:binding name="InferieurSoapBinding" type="impl:Inferieur">
<wsdlsoap:binding style="document" trans-
port="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="recevoirInsuffisant">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirInsuffisantRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirInsuffisantResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_enregistre">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_enregistreRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_enregistreResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_prepare">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_prepareRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_prepareResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Superieur_Valide">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_Superieur_ValideRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_Superieur_ValideResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_AccompliRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_AccompliResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Termine">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_TermineRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_TermineResponse">
Mayyad JABER 223
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="enregistre">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="enregistreRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="enregistreResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_GR_Pret">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_GR_PretRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_GR_PretResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoir_GR">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoir_GRRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoir_GRResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="envoyer_GR">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="envoyer_GRRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="envoyer_GRResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="notifierSuperieur">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="notifierSuperieurRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="notifierSuperieurResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="InferieurService">
<wsdl:port binding="impl:InferieurSoapBinding"
name="Inferieur">
<wsdlsoap:address loca-
tion="http://localhost:8080/Transactions/services/Inferieur"/>
</wsdl:port>
Mayyad JABER 224
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:service>
</wsdl:definitions>
A.4 Fichier WSDL du gestionnaire "supérieur/inférieur"
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://DefaultNamespace"
xmlns:intf="http://DefaultNamespace"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema elementFormDefault="qualified" targetNames-
pace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="attente_inferieurID">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_inferieurIDResponse">
<complexType/>
</element>
<element name="attente_WebService_Continue">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_WebService_ContinueResponse">
<complexType/>
</element>
<element name="attente_WebService_Valide">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_WebService_ValideResponse">
<complexType/>
</element>
<element name="attente_Accompli">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
Mayyad JABER 225
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<element name="attente_AccompliResponse">
<complexType/>
</element>
<element name="recevoirWebService">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="serviceID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoirWebServiceResponse">
<complexType/>
</element>
<element name="recevoirInsuffisant">
<complexType>
<sequence>
<element name="infID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="recevoirInsuffisantResponse">
<complexType/>
</element>
<element name="envoyerGestionnaire">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="infID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="envoyerGestionnaireResponse">
<complexType/>
</element>
<element name="envoyerServiceWeb">
<complexType>
<sequence>
<element name="list" type="impl:ArrayOf_xsd_anyType"/>
<element name="serviceID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<complexType name="ArrayOf_xsd_anyType">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="item"
type="xsd:anyType"/>
</sequence>
</complexType>
<element name="envoyerServiceWebResponse">
<complexType/>
</element>
<element name="attente_enregistre">
<complexType>
<sequence>
Mayyad JABER 226
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_enregistreResponse">
<complexType/>
</element>
<element name="attente_prepare">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_prepareResponse">
<complexType/>
</element>
<element name="attenteInferieurPret">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attenteInferieurPretResponse">
<complexType/>
</element>
<element name="attente_Superieur_Valide">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_Superieur_ValideResponse">
<complexType/>
</element>
<element name="attente_Termine">
<complexType>
<sequence>
<element name="delai" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="attente_TermineResponse">
<complexType/>
</element>
<element name="recevoirGestionnaire">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="infID" type="xsd:int"/>
</sequence>
</complexType>
</element>
Mayyad JABER 227
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<element name="recevoirGestionnaireResponse">
<complexType/>
</element>
<element name="enregistre">
<complexType>
<sequence>
<element name="infID" type="xsd:int"/>
<element name="list" type="impl:ArrayOf_xsd_anyType"/>
</sequence>
</complexType>
</element>
<element name="enregistreResponse">
<complexType/>
</element>
<element name="notifierSuperieur">
<complexType>
<sequence>
<element name="message" type="xsd:string"/>
<element name="SuperieurID" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="notifierSuperieurResponse">
<complexType/>
</element>
</schema>
</wsdl:types>
<wsdl:message name="envoyerGestionnaireRequest">
<wsdl:part element="impl:envoyerGestionnaire"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ContinueRequest">
<wsdl:part element="impl:attente_WebService_Continue"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantResponse">
<wsdl:part element="impl:recevoirInsuffisantResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliResponse">
<wsdl:part element="impl:attente_AccompliResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attenteInferieurPretRequest">
<wsdl:part element="impl:attenteInferieurPret"
name="parameters"/>
</wsdl:message>
<wsdl:message name="notifierSuperieurResponse">
<wsdl:part element="impl:notifierSuperieurResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_enregistreRequest">
<wsdl:part element="impl:attente_enregistre"
name="parameters"/>
</wsdl:message>
Mayyad JABER 228
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:message name="attente_inferieurIDResponse">
<wsdl:part element="impl:attente_inferieurIDResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerGestionnaireResponse">
<wsdl:part element="impl:envoyerGestionnaireResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerServiceWebResponse">
<wsdl:part element="impl:envoyerServiceWebResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_inferieurIDRequest">
<wsdl:part element="impl:attente_inferieurID"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_Superieur_ValideRequest">
<wsdl:part element="impl:attente_Superieur_Valide"
name="parameters"/>
</wsdl:message>
<wsdl:message name="enregistreResponse">
<wsdl:part element="impl:enregistreResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirWebServiceRequest">
<wsdl:part element="impl:recevoirWebService"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ValideRequest">
<wsdl:part element="impl:attente_WebService_Valide"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_prepareResponse">
<wsdl:part element="impl:attente_prepareResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="enregistreRequest">
<wsdl:part element="impl:enregistre" name="parameters"/>
</wsdl:message>
<wsdl:message name="envoyerServiceWebRequest">
<wsdl:part element="impl:envoyerServiceWeb"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_prepareRequest">
<wsdl:part element="impl:attente_prepare" name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_TermineRequest">
<wsdl:part element="impl:attente_Termine" name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirInsuffisantRequest">
<wsdl:part element="impl:recevoirInsuffisant"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirGestionnaireRequest">
Mayyad JABER 229
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:part element="impl:recevoirGestionnaire"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_enregistreResponse">
<wsdl:part element="impl:attente_enregistreResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_Superieur_ValideResponse">
<wsdl:part element="impl:attente_Superieur_ValideResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ContinueResponse">
<wsdl:part element="impl:attente_WebService_ContinueResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_TermineResponse">
<wsdl:part element="impl:attente_TermineResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="notifierSuperieurRequest">
<wsdl:part element="impl:notifierSuperieur"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_AccompliRequest">
<wsdl:part element="impl:attente_Accompli"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attenteInferieurPretResponse">
<wsdl:part element="impl:attenteInferieurPretResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirWebServiceResponse">
<wsdl:part element="impl:recevoirWebServiceResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="attente_WebService_ValideResponse">
<wsdl:part element="impl:attente_WebService_ValideResponse"
name="parameters"/>
</wsdl:message>
<wsdl:message name="recevoirGestionnaireResponse">
<wsdl:part element="impl:recevoirGestionnaireResponse"
name="parameters"/>
</wsdl:message>
<wsdl:portType name="Superieur_Inferieur">
<wsdl:operation name="attente_inferieurID">
<wsdl:input message="impl:attente_inferieurIDRequest"
name="attente_inferieurIDRequest"/>
<wsdl:output message="impl:attente_inferieurIDResponse"
name="attente_inferieurIDResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Continue">
<wsdl:input mes-
sage="impl:attente_WebService_ContinueRequest"
name="attente_WebService_ContinueRequest"/>
Mayyad JABER 230
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:output mes-
sage="impl:attente_WebService_ContinueResponse"
name="attente_WebService_ContinueResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Valide">
<wsdl:input mes-
sage="impl:attente_WebService_ValideRequest"
name="attente_WebService_ValideRequest"/>
<wsdl:output mes-
sage="impl:attente_WebService_ValideResponse"
name="attente_WebService_ValideResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdl:input message="impl:attente_AccompliRequest"
name="attente_AccompliRequest"/>
<wsdl:output message="impl:attente_AccompliResponse"
name="attente_AccompliResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirWebService">
<wsdl:input message="impl:recevoirWebServiceRequest"
name="recevoirWebServiceRequest"/>
<wsdl:output message="impl:recevoirWebServiceResponse"
name="recevoirWebServiceResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirInsuffisant">
<wsdl:input message="impl:recevoirInsuffisantRequest"
name="recevoirInsuffisantRequest"/>
<wsdl:output message="impl:recevoirInsuffisantResponse"
name="recevoirInsuffisantResponse"/>
</wsdl:operation>
<wsdl:operation name="envoyerGestionnaire">
<wsdl:input message="impl:envoyerGestionnaireRequest"
name="envoyerGestionnaireRequest"/>
<wsdl:output message="impl:envoyerGestionnaireResponse"
name="envoyerGestionnaireResponse"/>
</wsdl:operation>
<wsdl:operation name="envoyerServiceWeb">
<wsdl:input message="impl:envoyerServiceWebRequest"
name="envoyerServiceWebRequest"/>
<wsdl:output message="impl:envoyerServiceWebResponse"
name="envoyerServiceWebResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_enregistre">
<wsdl:input message="impl:attente_enregistreRequest"
name="attente_enregistreRequest"/>
<wsdl:output message="impl:attente_enregistreResponse"
name="attente_enregistreResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_prepare">
<wsdl:input message="impl:attente_prepareRequest"
name="attente_prepareRequest"/>
<wsdl:output message="impl:attente_prepareResponse"
name="attente_prepareResponse"/>
</wsdl:operation>
<wsdl:operation name="attenteInferieurPret">
Mayyad JABER 231
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:input message="impl:attenteInferieurPretRequest"
name="attenteInferieurPretRequest"/>
<wsdl:output message="impl:attenteInferieurPretResponse"
name="attenteInferieurPretResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Superieur_Valide">
<wsdl:input message="impl:attente_Superieur_ValideRequest"
name="attente_Superieur_ValideRequest"/>
<wsdl:output mes-
sage="impl:attente_Superieur_ValideResponse"
name="attente_Superieur_ValideResponse"/>
</wsdl:operation>
<wsdl:operation name="attente_Termine">
<wsdl:input message="impl:attente_TermineRequest"
name="attente_TermineRequest"/>
<wsdl:output message="impl:attente_TermineResponse"
name="attente_TermineResponse"/>
</wsdl:operation>
<wsdl:operation name="recevoirGestionnaire">
<wsdl:input message="impl:recevoirGestionnaireRequest"
name="recevoirGestionnaireRequest"/>
<wsdl:output message="impl:recevoirGestionnaireResponse"
name="recevoirGestionnaireResponse"/>
</wsdl:operation>
<wsdl:operation name="enregistre">
<wsdl:input message="impl:enregistreRequest"
name="enregistreRequest"/>
<wsdl:output message="impl:enregistreResponse"
name="enregistreResponse"/>
</wsdl:operation>
<wsdl:operation name="notifierSuperieur">
<wsdl:input message="impl:notifierSuperieurRequest"
name="notifierSuperieurRequest"/>
<wsdl:output message="impl:notifierSuperieurResponse"
name="notifierSuperieurResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="Superieur_InferieurSoapBinding"
type="impl:Superieur_Inferieur">
<wsdlsoap:binding style="document" trans-
port="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="attente_inferieurID">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_inferieurIDRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_inferieurIDResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Continue">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_WebService_ContinueRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
Mayyad JABER 232
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdl:output name="attente_WebService_ContinueResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_WebService_Valide">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_WebService_ValideRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_WebService_ValideResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Accompli">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_AccompliRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_AccompliResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirWebService">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirWebServiceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirWebServiceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirInsuffisant">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirInsuffisantRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirInsuffisantResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="envoyerGestionnaire">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="envoyerGestionnaireRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="envoyerGestionnaireResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="envoyerServiceWeb">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="envoyerServiceWebRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="envoyerServiceWebResponse">
Mayyad JABER 233
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_enregistre">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_enregistreRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_enregistreResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_prepare">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_prepareRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_prepareResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attenteInferieurPret">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attenteInferieurPretRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attenteInferieurPretResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Superieur_Valide">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_Superieur_ValideRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_Superieur_ValideResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="attente_Termine">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="attente_TermineRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="attente_TermineResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="recevoirGestionnaire">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="recevoirGestionnaireRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="recevoirGestionnaireResponse">
<wsdlsoap:body use="literal"/>
Mayyad JABER 234
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="enregistre">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="enregistreRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="enregistreResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="notifierSuperieur">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="notifierSuperieurRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="notifierSuperieurResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="Superieur_InferieurService">
<wsdl:port binding="impl:Superieur_InferieurSoapBinding"
name="Superieur_Inferieur">
<wsdlsoap:address loca-
tion="http://localhost:8080/Transactions/services/Superieur_Inferie
ur"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Mayyad JABER 235
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
INSA DE LYON, DÉPARTEMENT DES ÉTUDES DOCTORALE, Écoles Doctorales 2007-2010
SIGLE ECOLE DOCTORALE NOM ET COORDONNEES DU RESPONSABLE
CHIMIE
CHIMIE DE LYON
http://sakura.cpe.fr/ED206 M. Jean Marc LANCELIN
Insa : R. GOURDON
M. Jean Marc LANCELIN Université Claude Bernard Lyon 1
Bât CPE, 43 bd du 11 novembre 1918
69622 VILLEURBANNE Cedex Tél : 04.72.43 13 95 Fax :
E2M2
MICROBIOLOGIE, MODELISATION
http://biomserv.univ-lyon1.fr/E2M2
M. Jean-Pierre FLANDROIS
Insa : H. CHARLES
M. Jean-Pierre FLANDROIS
CNRS UMR 5558 Université Claude Bernard Lyon 1
Bât G. Mendel, 43 bd du 11 novembre 1918 69622 VILLEURBANNE Cédex
Tél : 04.26 23 59 50 Fax 04 26 23 59 49
06 07 53 89 13 [email protected]
E.E.A.
ELECTRONIQUE,
ELECTROTECHNIQUE, AUTOMATIQUE
http://www.insa-lyon.fr/eea
M. Alain NICOLAS Insa : D. BARBIER
Secrétariat : M. LABOUNE AM. 64.43 – Fax : 64.54
M. Alain NICOLAS
Ecole Centrale de Lyon Bâtiment H9
36 avenue Guy de Collongue 69134 ECULLY
Tél : 04.72.18 60 97 Fax : 04 78 43 37 17
[email protected] Secrétariat : M.C. HAVGOUDOUKIAN
EDIIS
INFORMATIQUE ET INFORMATION
POUR LA SOCIETE
http://ediis.univ-lyon1.fr
M. Alain MILLE
Secrétariat : I. BUISSON
M. Alain MILLE
Université Claude Bernard Lyon 1 LIRIS - EDIIS
Bâtiment Nautibus 43 bd du 11 novembre 1918
69622 VILLEURBANNE Cedex
Tél : 04.72. 44 82 94 Fax 04 72 44 80 53 [email protected] - [email protected]
EDISS
INTERDISCIPLINAIRE SCIENCESSANTE
Sec : Safia Boudjema
M. Didier REVEL
Insa : M. LAGARDE
M. Didier REVEL
Hôpital Cardiologique de Lyon Bâtiment Central, 28 Avenue Doyen Lépine
69500 BRON Tél : 04.72.68 49 09 Fax :04 72 35 49 16
Matériaux
MATERIAUX DE LYON
M. Jean Marc PELLETIER
Secrétariat : C. BERNAVON
83.85
M. Jean Marc PELLETIER
INSA de Lyon
MATEIS
Bâtiment Blaise Pascal, 7 avenue Jean Capelle 69621 VILLEURBANNE Cédex
Tél : 04.72.43 83 18 Fax 04 72 43 85 28 [email protected]
Math IF
MATHEMATIQUES ET INFORMATIQUE
FONDAMENTALE
M. Pascal KOIRAN
Insa : G. BAYADA
M.Pascal KOIRAN
Ecole Normale Supérieure de Lyon 46 allée d’Italie, 69364 LYON Cédex 07
Tél : 04.72.72 84 81 Fax : 04 72 72 89 69
[email protected] Secrétariat : Fatine Latif - [email protected]
MEGA
MECANIQUE, ENERGETIQUE, GENIE
CIVIL, ACOUSTIQUE
M. Jean Louis GUYADER
Secrétariat : M. LABOUNE
PM : 71.70 –Fax : 87.12
M. Jean Louis GUYADER
INSA de Lyon Laboratoire de Vibrations et Acoustique
Bâtiment Antoine de Saint Exupéry 25 bis avenue Jean Capelle
69621 VILLEURBANNE Cedex
Tél :04.72.18.71.70 Fax : 04 72 18 87 12 [email protected]
ScSo ScSo
M. BRAVARD Jean Paul
Insa : J.Y. TOUSSAINT
M. BRAVARD Jean Paul
Université Lyon 2, 86 rue Pasteur 69365 LYON Cedex 07
Tél : 04.78.69.72.76 Fax : 04.37.28.04.48 [email protected]
Mayyad JABER 236
Thèse en informatique / 2009
Institut National des Sciences Appliquées de Lyon
FOLIO ADMINISTRATIF
THESE SOUTENUE DEVANT L’INSTITUT NATIONAL DES SCIENCES APLQUEES
DE LYON
NOM : JABER
Prénoms : Mayyad
Date de soutenance
Février 2008
TITRE : Architecture de système d’information distribué pour la gestion de la chaîne logistique
NATURE : Doctorat Ecole doctorale : EDIIS Numéro d’ordre :
Spécialité : Informatique
Cote B.I.U. – Lyon : T 50/210/19 / et bis CLASSE :
RESUME :
Afin d’améliorer leur compétitivité, les entreprises cherchent à réduire le coût de leurs processus
métiers, et d’augmenter leur capacité de développement rapide pour des nouveaux services et
produits. Pour cela, les entreprises se concentrent de plus en plus sur leur cœur de métier alors
qu’ils sont de plus en plus impliqués dans des collaborations dans leur environnement. Cette
tendance implique le renforcement des relations de collaboration avec des partenaires menant aux
organisations virtuelles. Ces organisations interentreprises doivent payer une attention particulière
sur les opérations logistiques, de l’approvisionnement à la distribution des produits finaux.
L’amélioration de la performance globale d’une telle chaîne logistique repose sur l’optimisation du
processus industriel mais aussi sur un processus efficace de coordination et de partage de
l’information entre les partenaires. La mise en œuvre du processus de la chaîne logistique repose
largement sur les technologies de l’information et de la communication. Ils conduisent à dépasser
les frontières les entreprises et ensuite créer de nouvelles occasions de business.
L’idée de cœur de notre approche repose sur une vision globale de collaboration flexible
entre les partenaires de la chaîne logistique. Cela est réalisé par le biais d’un cadre global fondé sur
des technologies et des normes neutres pour supporter la gestion de collaboration. Dans ce travail,
nous présentons un cadre intégré pour la collaboration interentreprises. Le principe du cadre est
basé sur la facilitation de l’accès aux processus des systèmes patrimoniaux et la définition des
processus métiers communs par l’assemblage de services distribués sous forme d’un Workflow
global. L’engagement potentiel de plusieurs systèmes patrimoniaux hétérogènes dans un processus
commun collaboratif est associé à plus forte exigence d’interopérabilité pour l’organisation de
processus métiers et pour l’échange d’informations. Ces contraintes imposent une infrastructure
flexible au niveau de systèmes d’information et de systèmes de communication.
En outre, le cadre gère les transactions. Il propose notamment une gestion de ressources et
de transactions distribuées afin d’orchestrer des services lâchement couplés dans des unités
interconnectées et de garantir une exécution correcte et fiable pour le processus commun. Ainsi, les
définitions nécessaires et les algorithmes qui peuvent maintenir constamment les ressources
partagées sont fournis offrant un processus cohérent au travers de multiples systèmes d ’information
autonomes et de systèmes de Workflow locaux de partenaires.
MOTS CLES : Chaîne logistique; Collaboration interentreprises; processus métier; Architecture
orientée service; Workflow; Transactions distribuées.
Laboratoire(s) de recherches : LIESP
Directeur de thèse : Pr. Frédérique BIENNIER
Composition du jury : Valérie ISSARNY, Hervé PINGAUD, Dominique RIEU, Youakim BADR,
Frédérique BIENNIER