architecture de système d’information distribué pour la...

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



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



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



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



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



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



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



Mayyad JABER 1



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



métier et les techniques permettant la coordination de processus métier

distribué pour construire le processus commun.

Mayyad JABER 26



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



[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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



é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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



é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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



à 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



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



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



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



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



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



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



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



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



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



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



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



Figure 5-5 Rôle de médiateur dans un e-approvisionnement

Mayyad JABER 98



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



Figure 7-10 Transitions d’état pour un gestionnaire de transaction racine

Mayyad JABER 146



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



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 :


racine entame la phase "Avorte_Transaction".

Mayyad JABER 148



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


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


à tous les gestionnaires inférieurs de restaurer leur état initial. Il envoie

Mayyad JABER 149



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


à 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



Mayyad JABER 151



Figure 7-11 Gestionnaire de transaction racine

Mayyad JABER 152



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)


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 :


du message "Prépare Inférieur_ID" venant du gestionnaire

de niveau supérieur. Dans ce cas, le gestionnaire inférieur

Mayyad JABER 153



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


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.


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)


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 :


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



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



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 :


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



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.


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



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



Mayyad JABER 159



Mayyad JABER 160



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



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 :


du message d’enregistrement du gestionnaire de niveau

supérieur. Dans ce cas, le gestionnaire supérieur/inférieur


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"


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



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)


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 :


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


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 :


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



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.


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


toutes les réponses des gestionnaires de niveau inférieur.

Mayyad JABER 164



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



(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



(Atn_WS_Valide).

Etat d’attente de validation du service associé (Atn_WS_Valide)


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 :


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



Etat d’attente de validation (Atn_Valide)


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


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)



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



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)


reçoit les réponses des gestionnaires de niveau inférieur à ses messages

Mayyad JABER 166



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.


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)


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



Phase de retour en arrière



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




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



Mayyad JABER 169



Mayyad JABER 170



Figure 7-13 Gestionnaire de transaction Supérieur/Inférieur

Mayyad JABER 171



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



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



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



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



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



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



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



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



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



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



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



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


traitement des demandes de devis chez le fournisseur 1.

Fournisseur 2



Fournisseur 3

Mayyad JABER 183





Figure 8-3 Services Web participant au processus commun d ’e-

approvisionnement

Mayyad JABER 184



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



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



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



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



Figure 8-6 Diagramme de séquence pour les composants du processus

commun

Mayyad JABER 189



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



Figure 8-7 Intégration des gestionnaires de transaction dans les differentes

configurations du processus d’e-approvisionnement

Mayyad JABER 191



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



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



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



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



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



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



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.

http://dev2dev.bea.com/soa/%22

Mayyad JABER 198



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.

http://www.bpmi.org/%22

Mayyad JABER 199



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.

http://www.research.ibm.com/iac/papers/icdcsws99.pdf%22

http://www.application-servers.com/livresblancs%22

Mayyad JABER 200



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"


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

http://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf

http://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf

http://docs.jboss.org/jbosside/cookbook/build/en/pdf/JBossIDE-Cookbook.pdf%22

Mayyad JABER 201



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"


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.

http://www.loria.fr/projets/calife/WebCalifePublic/FOURNITURES/F1.2.doc

Mayyad JABER 202



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


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.

http://www.omg.org/%22

http://www.omg.org/%22

Mayyad JABER 203



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.

http://www.rosettanet.org/%22

http://www.supply-chain.org/galleries/public-gallery/SCOR

Mayyad JABER 204



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.

http://www.w3.org/TR/SOAP/%22

http://pavg.stanford.edu/rapide/examples/xopen/%22

http://www.uddi.org/%22

Mayyad JABER 205



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.

http://www.wfmc.org/%22

http://www.opengroup.org/onlinepubs/009680699/toc.pdf

http://msdn.microsoft.com/library/%22

Mayyad JABER 206



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="listGR" type="impl:ArrayOf_xsd_anyType"/>

</sequence>

</complexType>

</element>

<element name="creeInferieurResponse">

<complexType/>

</element>

<element name="creeSuperieur_Inferieur">

<complexType>

Mayyad JABER 207



<sequence>

<element name="Superieur_InferieurID" 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



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


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="creeInferieur">


<wsdl:input name="creeInferieurRequest">


</wsdl:input>

<wsdl:output name="creeInferieurResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="creeSuperieur_Inferieur">


<wsdl:input name="creeSuperieur_InferieurRequest">


</wsdl:input>

<wsdl:output name="creeSuperieur_InferieurResponse">


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









<wsdl:types>




Mayyad JABER 209



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


</sequence>

</complexType>

</element>

<element name="attente_WebService_ContinueResponse">

<complexType/>

</element>

<element name="AttenteInferieurPret">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="AttenteInferieurPretResponse">

<complexType/>

</element>

<element name="attente_WebService_Valide">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_WebService_ValideResponse">

<complexType/>

</element>

<element name="attente_Accompli">

<complexType>

<sequence>


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



</sequence>

</complexType>

</element>

<element name="recevoirInferieurResponse">

<complexType/>

</element>

<element name="recevoirWebService">

<complexType>

<sequence>


<element name="serviceID" type="xsd:int"/>

</sequence>

</complexType>

</element>

<element name="recevoirWebServiceResponse">

<complexType/>

</element>

<element name="enregister">

<complexType>

<sequence>


<element name="list" type="impl:ArrayOf_xsd_anyType"/>

</sequence>

</complexType>

</element>


<sequence>



</sequence>

</complexType>

<element name="enregisterResponse">

<complexType/>

</element>

<element name="recevoirInsuffisant">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="recevoirInsuffisantResponse">

<complexType/>

</element>

<element name="envoyerGestionnaire">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="envoyerGestionnaireResponse">

<complexType/>

</element>

Mayyad JABER 211



<element name="envoyerServiceWeb">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="envoyerServiceWebResponse">

<complexType/>

</element>

<element name="notifierWebService">

<complexType>

<sequence>


<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



<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



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



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





<wsdl:input name="attente_inferieurIDRequest">


</wsdl:input>

<wsdl:output name="attente_inferieurIDResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_WebService_ContinueRequest">


</wsdl:input>

<wsdl:output name="attente_WebService_ContinueResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="AttenteInferieurPret">


Mayyad JABER 215



<wsdl:input name="AttenteInferieurPretRequest">


</wsdl:input>

<wsdl:output name="AttenteInferieurPretResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_WebService_ValideRequest">


</wsdl:input>

<wsdl:output name="attente_WebService_ValideResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_AccompliRequest">


</wsdl:input>

<wsdl:output name="attente_AccompliResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="recevoirInferieur">


<wsdl:input name="recevoirInferieurRequest">


</wsdl:input>

<wsdl:output name="recevoirInferieurResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="recevoirWebServiceRequest">


</wsdl:input>

<wsdl:output name="recevoirWebServiceResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="enregister">


<wsdl:input name="enregisterRequest">


</wsdl:input>

<wsdl:output name="enregisterResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="recevoirInsuffisantRequest">

Mayyad JABER 216




</wsdl:input>

<wsdl:output name="recevoirInsuffisantResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="envoyerGestionnaireRequest">


</wsdl:input>

<wsdl:output name="envoyerGestionnaireResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="envoyerServiceWebRequest">


</wsdl:input>

<wsdl:output name="envoyerServiceWebResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="notifierWebService">


<wsdl:input name="notifierWebServiceRequest">


</wsdl:input>

<wsdl:output name="notifierWebServiceResponse">


</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="RacineService">

<wsdl:port binding="impl:RacineSoapBinding" name="Racine">


tion="http://localhost:8080/Transactions/services/Racine"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

A.3 Fichier WSDL du gestionnaire "inférieur"









<wsdl:types>

Mayyad JABER 217







<complexType>

<sequence>

<element name="Gr_ID" type="xsd:int"/>

</sequence>

</complexType>

</element>


<complexType/>

</element>

<element name="attente_enregistre">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_enregistreResponse">

<complexType/>

</element>

<element name="attente_prepare">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_prepareResponse">

<complexType/>

</element>

<element name="attente_Superieur_Valide">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_Superieur_ValideResponse">

<complexType/>

</element>


<complexType>

<sequence>


</sequence>

</complexType>

</element>


<complexType/>

</element>

<element name="attente_Termine">

<complexType>

Mayyad JABER 218



<sequence>


</sequence>

</complexType>

</element>

<element name="attente_TermineResponse">

<complexType/>

</element>

<element name="enregistre">

<complexType>

<sequence>

<element name="GR_ID" type="xsd:int"/>


</sequence>

</complexType>

</element>


<sequence>



</sequence>

</complexType>

<element name="enregistreResponse">

<complexType/>

</element>

<element name="attente_GR_Pret">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_GR_PretResponse">

<complexType/>

</element>

<element name="recevoir_GR">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="recevoir_GRResponse">

<complexType/>

</element>

<element name="envoyer_GR">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="envoyer_GRResponse">

Mayyad JABER 219



<complexType/>

</element>

<element name="notifierSuperieur">

<complexType>

<sequence>


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



name="parameters"/>

</wsdl:message>



name="parameters"/>

</wsdl:message>



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



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



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>

<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



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

<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



</wsdl:portType>

<wsdl:binding name="InferieurSoapBinding" type="impl:Inferieur">







</wsdl:input>



</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_enregistreRequest">


</wsdl:input>

<wsdl:output name="attente_enregistreResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_prepareRequest">


</wsdl:input>

<wsdl:output name="attente_prepareResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_Superieur_ValideRequest">


</wsdl:input>

<wsdl:output name="attente_Superieur_ValideResponse">


</wsdl:output>

</wsdl:operation>





</wsdl:input>



</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_TermineRequest">


</wsdl:input>

<wsdl:output name="attente_TermineResponse">

Mayyad JABER 223




</wsdl:output>

</wsdl:operation>



<wsdl:input name="enregistreRequest">


</wsdl:input>

<wsdl:output name="enregistreResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="attente_GR_Pret">


<wsdl:input name="attente_GR_PretRequest">


</wsdl:input>

<wsdl:output name="attente_GR_PretResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="recevoir_GR">


<wsdl:input name="recevoir_GRRequest">


</wsdl:input>

<wsdl:output name="recevoir_GRResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="envoyer_GR">


<wsdl:input name="envoyer_GRRequest">


</wsdl:input>

<wsdl:output name="envoyer_GRResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="notifierSuperieurRequest">


</wsdl:input>

<wsdl:output name="notifierSuperieurResponse">


</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="InferieurService">

<wsdl:port binding="impl:InferieurSoapBinding"

name="Inferieur">


tion="http://localhost:8080/Transactions/services/Inferieur"/>

</wsdl:port>

Mayyad JABER 224



</wsdl:service>

</wsdl:definitions>

A.4 Fichier WSDL du gestionnaire "supérieur/inférieur"









<wsdl:types>




<element name="attente_inferieurID">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_inferieurIDResponse">

<complexType/>

</element>

<element name="attente_WebService_Continue">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_WebService_ContinueResponse">

<complexType/>

</element>

<element name="attente_WebService_Valide">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_WebService_ValideResponse">

<complexType/>

</element>


<complexType>

<sequence>


</sequence>

</complexType>

</element>

Mayyad JABER 225




<complexType/>

</element>

<element name="recevoirWebService">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="recevoirWebServiceResponse">

<complexType/>

</element>


<complexType>

<sequence>


</sequence>

</complexType>

</element>


<complexType/>

</element>

<element name="envoyerGestionnaire">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="envoyerGestionnaireResponse">

<complexType/>

</element>

<element name="envoyerServiceWeb">

<complexType>

<sequence>



</sequence>

</complexType>

</element>


<sequence>



</sequence>

</complexType>

<element name="envoyerServiceWebResponse">

<complexType/>

</element>

<element name="attente_enregistre">

<complexType>

<sequence>

Mayyad JABER 226




</sequence>

</complexType>

</element>

<element name="attente_enregistreResponse">

<complexType/>

</element>

<element name="attente_prepare">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_prepareResponse">

<complexType/>

</element>

<element name="attenteInferieurPret">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attenteInferieurPretResponse">

<complexType/>

</element>

<element name="attente_Superieur_Valide">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_Superieur_ValideResponse">

<complexType/>

</element>

<element name="attente_Termine">

<complexType>

<sequence>


</sequence>

</complexType>

</element>

<element name="attente_TermineResponse">

<complexType/>

</element>

<element name="recevoirGestionnaire">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

Mayyad JABER 227



<element name="recevoirGestionnaireResponse">

<complexType/>

</element>

<element name="enregistre">

<complexType>

<sequence>



</sequence>

</complexType>

</element>

<element name="enregistreResponse">

<complexType/>

</element>

<element name="notifierSuperieur">

<complexType>

<sequence>


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



name="parameters"/>

</wsdl:message>



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



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



name="parameters"/>

</wsdl:message>

<wsdl:message name="recevoirGestionnaireRequest">

Mayyad JABER 229



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



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:input message="impl:attente_inferieurIDRequest"

name="attente_inferieurIDRequest"/>

<wsdl:output message="impl:attente_inferieurIDResponse"

name="attente_inferieurIDResponse"/>

</wsdl:operation>


<wsdl:input mes-

sage="impl:attente_WebService_ContinueRequest"

name="attente_WebService_ContinueRequest"/>

Mayyad JABER 230



<wsdl:output mes-

sage="impl:attente_WebService_ContinueResponse"

name="attente_WebService_ContinueResponse"/>

</wsdl:operation>


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


<wsdl:input message="impl:recevoirWebServiceRequest"

name="recevoirWebServiceRequest"/>

<wsdl:output message="impl:recevoirWebServiceResponse"

name="recevoirWebServiceResponse"/>

</wsdl:operation>






</wsdl:operation>


<wsdl:input message="impl:envoyerGestionnaireRequest"

name="envoyerGestionnaireRequest"/>

<wsdl:output message="impl:envoyerGestionnaireResponse"

name="envoyerGestionnaireResponse"/>

</wsdl:operation>


<wsdl:input message="impl:envoyerServiceWebRequest"

name="envoyerServiceWebRequest"/>

<wsdl:output message="impl:envoyerServiceWebResponse"

name="envoyerServiceWebResponse"/>

</wsdl:operation>


<wsdl:input message="impl:attente_enregistreRequest"

name="attente_enregistreRequest"/>

<wsdl:output message="impl:attente_enregistreResponse"

name="attente_enregistreResponse"/>

</wsdl:operation>


<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



<wsdl:input message="impl:attenteInferieurPretRequest"

name="attenteInferieurPretRequest"/>

<wsdl:output message="impl:attenteInferieurPretResponse"

name="attenteInferieurPretResponse"/>

</wsdl:operation>


<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: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:input message="impl:enregistreRequest"

name="enregistreRequest"/>

<wsdl:output message="impl:enregistreResponse"

name="enregistreResponse"/>

</wsdl:operation>


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





<wsdl:input name="attente_inferieurIDRequest">


</wsdl:input>

<wsdl:output name="attente_inferieurIDResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_WebService_ContinueRequest">


</wsdl:input>

Mayyad JABER 232



<wsdl:output name="attente_WebService_ContinueResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_WebService_ValideRequest">


</wsdl:input>

<wsdl:output name="attente_WebService_ValideResponse">


</wsdl:output>

</wsdl:operation>





</wsdl:input>



</wsdl:output>

</wsdl:operation>



<wsdl:input name="recevoirWebServiceRequest">


</wsdl:input>

<wsdl:output name="recevoirWebServiceResponse">


</wsdl:output>

</wsdl:operation>





</wsdl:input>



</wsdl:output>

</wsdl:operation>



<wsdl:input name="envoyerGestionnaireRequest">


</wsdl:input>

<wsdl:output name="envoyerGestionnaireResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="envoyerServiceWebRequest">


</wsdl:input>

<wsdl:output name="envoyerServiceWebResponse">

Mayyad JABER 233




</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_enregistreRequest">


</wsdl:input>

<wsdl:output name="attente_enregistreResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_prepareRequest">


</wsdl:input>

<wsdl:output name="attente_prepareResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="attenteInferieurPret">


<wsdl:input name="attenteInferieurPretRequest">


</wsdl:input>

<wsdl:output name="attenteInferieurPretResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_Superieur_ValideRequest">


</wsdl:input>

<wsdl:output name="attente_Superieur_ValideResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="attente_TermineRequest">


</wsdl:input>

<wsdl:output name="attente_TermineResponse">


</wsdl:output>

</wsdl:operation>

<wsdl:operation name="recevoirGestionnaire">


<wsdl:input name="recevoirGestionnaireRequest">


</wsdl:input>

<wsdl:output name="recevoirGestionnaireResponse">


Mayyad JABER 234



</wsdl:output>

</wsdl:operation>



<wsdl:input name="enregistreRequest">


</wsdl:input>

<wsdl:output name="enregistreResponse">


</wsdl:output>

</wsdl:operation>



<wsdl:input name="notifierSuperieurRequest">


</wsdl:input>

<wsdl:output name="notifierSuperieurResponse">


</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="Superieur_InferieurService">

<wsdl:port binding="impl:Superieur_InferieurSoapBinding"

name="Superieur_Inferieur">


tion="http://localhost:8080/Transactions/services/Superieur_Inferie

ur"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Mayyad JABER 235



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 :

[email protected]

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

[email protected]

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

[email protected]

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]

http://sakura.cpe.fr/ED206

http://biomserv.univ-lyon1.fr/E2M2

http://www.insa-lyon.fr/eea

http://ediis.univ-lyon1.fr/

Mayyad JABER 236



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

architecture de système d’information distribué pour la...

Documents