Tebib Assia

République Algérienne Démocratique et Populaire
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE CONSTANTINE 2
Faculté des Nouvelles Technologies de
l’Information et de la Communication
N° d’ordre : ……………………….
Série : …………………….…
THESE
Présentée pour obtenir le Diplôme de Doctorat en Sciences
Sujet:
Concepts et Outils pour l’Intégration et

l’Interopérabilité des Services.
Application dans le cadre du
E-Government.
Présentée par : Tebib Assia Dirigée par : Professeur Boufaida Mahmoud
Soutenue à Constantine le : 27/11/2014
Devant le jury :
Président : ZAROUR Nacereddine Professeur à l’université de Constantine 2
Rapporteur : BOUFAIDA Mahmoud Professeur à l’université de Constantine 2
Examinateurs: FARAH Nadir Professeur à l’université de Annaba

CHIKHI Salim Professeur à l’université de Constantine 2
MOKHATI Farid Maitre de conférence A à l’université d’Oum El Bouaghi
Remerciements
D'abord, louange à DIEU, le tout puissant, que je remercie beaucoup de m'avoir donné la
force et le courage de terminer cette thèse. Sans lui, rien n’aurait pu être réalisé.
Tout d’abord, je tiens à remercier et exprimer toute ma reconnaissance auprès de mon

encadreur monsieur, Mahmoud Boufaida, Professeur à l'université Constantine 2. Il m’a initié
à la recherche dans un domaine qui m’a toujours motivé. Méticuleux et perfectionniste,
toujours disponible, il m’a prodigué des conseils inestimables, dans tous les domaines, tout au
long de ma thèse. Je suis très fière de la formation de chercheuse acquise sous son
encadrement. Je le remercie très fort et je m’excuse auprès de sa noble personne de lui avoir
pris beaucoup de son temps.
Je tiens aussi à remercier Monsieur Mr. ZAROUR Nacereddine, Professeur à l'université

Constantine 2 de m’avoir fait l’honneur d’accepter de présider le jury de ma soutenance de
thèse, ainsi que :
• Monsieur Mr. FARAH Nadir Professeur à l’université de Annaba,
• Monsieur Mr. CHIKHI Salim Professeur à l’université de Constantine 2,
• Monsieur Mr. MOKHATI Farid Maitre de conférence A à l’université d’Oum El
Bouaghi.
Pour l’honneur d'avoir accepté de faire partie de ce jury en tant qu'examinateurs.
Enfin, je tiens à présenter mes remerciements les plus sincères à ma famille. A mes parents,
pour leurs soutiens et encouragements de tous les instants et sans qui cette aventure n’aurait
jamais vu le jour. Mes pensées vont également vers ma sœur Housna et mon frère Abdel
Karim, à ma petite famille mes deux enfants lyna et Akram sans oublier mon mari Abdelkrim.
Enfin, je n'omettrais pas de remercier vivement les membres de l'équipe du Laboratoire
d'Informatique LIRE de Constantine, et en particulier les membres de l'équipe SIBC
(Systèmes d'Information & bases de Données), doctorants, magisters et LMD avec lesquels
j'ai pu échanger des idées, discuter, et enfin partager et vivre des moments agréables parmi
eux.
Titre : « Concepts et Outils pour l’Intégration et l’Interopérabilité des
Services. Application dans le cadre du E-Government »
Résumé : L'intégration et l’interopérabilité des processus métiers dans un

environnement de e-service (electronic service) constituent un problème clé et
des exigences de base dans le développement d’applications orientées services
en interaction qui doivent être résolues de toute urgence. En effet, dans le cadre
d'applications de e-service, les protocoles d'interaction (PI) sont des descriptions
des comportements observables des participants. Ils sont considérés comme un
moyen efficace pour structurer et organiser les échanges de messages entre
partenaires. Lorsque ces derniers collaborent, leur PI peut être utilisé pour
vérifier si leur collaboration est bonne, c'est à dire, les applications sont
conformes. Dans cette thèse, nous définissons un PI efficace qui peut être utilisé
pour vérifier si une application peut correctement jouer un rôle spécifique. Pour
cette raison, nous présentons une cartographie complète et rigoureusement
définie du PI qui utilise une notation semi-formelle AUML, puis passe vers le
langage BPEL4WS pour être formalisé à la fin en π-calcul. Certaines propriétés
dynamiques ont été vérifiées à l’aide du pi-logique. Ensuite, ce protocole sera
exploité dans une architecture basée agents qui est composée de deux parties : le
front office et le back office. La première, permet aux utilisateurs de
sélectionner le meilleur service directement du portail e-service en utilisant les
agents intelligents. La deuxième partie, permet de décrire comment le SMA
utilise le PI vérifié et validé. Nous définissons l’ensemble des concepts
nécessaires pour assurer toutes les phases de l'intégration et de l’interopérabilité.
En outre, nous décrivons l'utilisation du PI pour définir et gérer les processus
d’intégration et d’interopérabilité dans les relations de l'e-service, où
l'autonomie des participants est préservée.
Mots-clés Intégration, Interopérabilité, Processus Métier, Protocole

d’Interaction, AUML, BPEL4WS, π-calcul, π-logique
Title : « Concepts and Tools for Integration and Interoperability of
Services. Application in the context of E-Government»
Abstract: Integration and interoperability of business processes in an

environment of e-services (electronic service) is a key problem and the basic
requirements in service-oriented application development in interaction that
must be resolved urgently. Indeed, in the application of e-services context,
Interaction Protocols (IP) are descriptions of the observable behaviors of
participants. They are considered an effective way to structure and organize the
exchange of messages between partners. When they collaborate, their IP can be
used to check if their collaboration is good, that is, applications are compliant. In
this thesis, we define an effective IP that can be used to check whether an
application can correctly play a specific role. For this reason, we present a
comprehensive and rigorously defined mapping of IP that uses the AUML semi-
formal notation, and then passes to the BPEL4WS language to be formalized at
the end in π-calculus. Some dynamic properties were verified using π-logic.
Then, the protocol will operate in an architecture based agents which consists of
two parts: the front office and the back one. The first part, allows users to select
the best service directly from the portal e-service using intelligent agents. The
second part, used to describe how the MAS uses the IP verified and validated.
We define all the concepts necessary for all phases of integration and
interoperability. In addition, we describe the use of IP for defining and
managing the processes of integration and interoperability in the relations of e-
services, where the autonomy of participants is preserved.
Keywords Integration, interoperability, business process, interaction

protocol , AUML, BPEL4WS, π-calculus, π-logic
‫”ﻣﻔﺎهﻴﻢ وأدوات ﻟﺪﻣﺞ واﻟﺘﺸﻐﻴﻞ اﻟﺒﻴﻨﻲ ﻟﻠﺨﺪﻣﺎت‪ .‬اﻟﺘﻄﺒﻴﻖ ﻓﻲ إﻃﺎر اﻟﺤﻜﻮﻣﺔ اﻻﻟﻜﺘﺮوﻧﻴﺔ’‘‬
‫ﻣﻠﺨﺺ‬
‫اﻟﺘﻜﺎﻣﻞ واﻟﻌﻤﻞ اﻟﻤﺸﺘﺮك ﻟﻌﻤﻠﻴﺔ ﺗﺠﺎرﻳﺔ ﻓﻲ ﺑﻴﺌﺔ ﻣﻦ اﻟﺨﺪﻣﺎت اﻹﻟﻜﺘﺮوﻧﻴﺔ )ﺧﺪﻣﺔ اﻹﻟﻜﺘﺮوﻧﻴﺔ( هﻮ اﻟﻤﺸﻜﻠﺔ‬
‫اﻟﺮﺋﻴﺴﻴﺔ واﻟﻤﺘﻄﻠﺒﺎت اﻷﺳﺎﺳﻴﺔ ﻓﻲ ﺗﻄﻮﻳﺮ اﻟﺘﻄﺒﻴﻘﺎت اﻟﻤﻮﺟﻬﺔ ﻧﺤﻮ اﻟﺨﺪﻣﺎت ﻓﻲ ﺗﻔﺎﻋﻞ اﻟﺘﻲ ﻳﺠﺐ ﺣﻠﻬﺎ ﻋﻠﻰ‬
‫وﺟﻪ اﻟﺴﺮﻋﺔ‪ .‬ﻓﻲ اﻟﻮاﻗﻊ‪ ،‬ﻓﻲ إﻃﺎر ﺗﻄﺒﻴﻖ اﻟﺨﺪﻣﺎت اﻹﻟﻜﺘﺮوﻧﻴﺔ واﻟﺒﺮوﺗﻮآﻮﻻت ﺗﻔﺎﻋﻞ ﻓﻬﻲ أوﺻﺎف‬
‫اﻟﺴﻠﻮك اﻟﺘﻲ ﻳﻤﻜﻦ ﻣﻼﺣﻈﺘﻬﺎ ﻣﻦ اﻟﻤﺸﺎرآﻴﻦ‪ .‬ﻓﻬﻲ ﺗﻌﺘﺒﺮ وﺳﻴﻠﺔ ﻓﻌﺎﻟﺔ ﻟﻬﻴﻜﻠﺔ وﺗﻨﻈﻴﻢ ﺗﺒﺎدل اﻟﺮﺳﺎﺋﻞ ﺑﻴﻦ‬
‫اﻟﺸﺮآﺎء‪ .‬ﻋﻨﺪﻣﺎ ﻳﻌﻤﻠﻮن ﻣﻌﺎ‪ ،‬وﻳﻤﻜﻦ اﺳﺘﺨﺪام ‪ PI‬ﻟﻤﻌﺮﻓﺔ ﻣﺎ اذا آﺎن ﺗﻌﺎوﻧﻬﻢ ﺟﻴﺪ‪ ،‬وهﺬا هﻮ‪ ،‬ﺗﻄﺒﻴﻘﺎت‬
‫ﻣﺘﻮاﻓﻘﺔ‪ .‬ﻓﻲ هﺬﻩ اﻷﻃﺮوﺣﺔ‪ ،‬ﻓﺈﻧﻨﺎ ﻧﻘﻮم ﺑﺘﻌﺮﻳﻒ ﻓﻌﺎل ﻟﻠﻤﻠﻜﻴﺔ اﻟﻔﻜﺮﻳﺔ اﻟﺘﻲ ﻳﻤﻜﻦ اﺳﺘﺨﺪاﻣﻬﺎ ﻟﻠﺘﺤﻘﻖ ﻣﺎ إذا‬
‫آﺎن اﻟﺘﻄﺒﻴﻖ ﻳﻤﻜﻦ أن ﻳﻠﻌﺐ دورا ﻣﺤﺪدا ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪ .‬ﻟﻬﺬا اﻟﺴﺒﺐ‪ ،‬ﻧﻘﺪم ﺧﺮاﺋﻂ ﺷﺎﻣﻠﺔ وﻣﺤﺪدة ﺑﺪﻗﺔ ﻣﻦ‬
‫‪ PI‬اﻟﺬي ﻳﺴﺘﺨﺪم اﻟﺘﺪوﻳﻦ اﻟﺸﺒﻪ اﻟﺮﺳﻤﻲ ‪ ،AUML‬ﺛﻢ ﻳﻤﺮ إﻟﻰ اﻟﻠﻐﺔ ‪ BPEL4WS‬إﻟﻰ إﺿﻔﺎء اﻟﻄﺎﺑﻊ‬
‫اﻟﺮﺳﻤﻲ ﻓﻲ ﻧﻬﺎﻳﺔ ‪-π‬ﻓﻲ ﺣﺴﺎب اﻟﺘﻔﺎﺿﻞ واﻟﺘﻜﺎﻣﻞ‪ .‬وﺗﻢ اﻟﺘﺤﻘﻖ ﻣﻦ ﺑﻌﺾ اﻟﺨﺼﺎﺋﺺ اﻟﺪﻳﻨﺎﻣﻴﻜﻴﺔ ﺑﺎﺳﺘﺨﺪام‬
‫‪ -π‬اﻟﻤﻨﻄﻖ‪ .‬ﺛﻢ‪ ،‬ﻓﺈن ﺑﺮوﺗﻮآﻮل ﻳﻌﻤﻞ ﻓﻲ هﻴﻜﻠﺔ ﻗﺴﻤﺔ اﻟﻰ ﻗﺴﻤﻴﻦ‪ :‬اﻟﻤﻜﺘﺐ اﻷﻣﺎﻣﻲ واﻟﻤﻜﺘﺐ اﻟﺨﻠﻔﻲ‪ .‬اﻷول‬
‫ﻳﺴﻤﺢ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﻻﺧﺘﻴﺎر أﻓﻀﻞ ﺧﺪﻣﺔ ﻣﺒﺎﺷﺮة ﻣﻦ ﺧﺪﻣﺔ اﻟﺒﻮاﺑﺔ اﻹﻟﻜﺘﺮوﻧﻴﺔ ﺑﺎﺳﺘﺨﺪام وآﻼء ذآﺎء‪ .‬اﻟﺠﺰء‬
‫اﻟﺜﺎﻧﻲ‪ ،‬ﻳﺴﺘﺨﺪم ﻟﻮﺻﻒ آﻴﻒ ﻳﺴﺘﺨﺪم ‪ SMA‬ﻓﻲ ‪ PI‬واﻟﺘﺤﻘﻖ ﻣﻦ ﺻﺤﺘﻬﺎ‪ .‬ﻧﺤﺪد ﺟﻤﻴﻊ اﻟﻤﻔﺎهﻴﻢ اﻟﻼزﻣﺔ‬
‫ﻟﺠﻤﻴﻊ ﻣﺮاﺣﻞ اﻟﺘﻜﺎﻣﻞ واﻟﻌﻤﻞ اﻟﻤﺸﺘﺮك‪ .‬وﺑﺎﻹﺿﺎﻓﺔ إﻟﻰ ذﻟﻚ‪ ،‬ﻧﺤﻦ ﻧﺴﺘﺨﺪم ‪ PI‬ﻟﺘﺤﺪﻳﺪ وإدارة ﻋﻤﻠﻴﺎت‬
‫اﻟﺘﻜﺎﻣﻞ واﻟﻌﻤﻞ اﻟﻤﺸﺘﺮك ﻓﻲ اﻟﻌﻼﻗﺎت اﻟﺨﺪﻣﺎت اﻹﻟﻜﺘﺮوﻧﻴﺔ‪ ،‬ﺣﻴﺚ ﻳﺘﻢ اﻟﺤﻔﺎظ ﻋﻠﻰ اﺳﺘﻘﻼﻟﻴﺔ اﻟﻤﺸﺎرآﻴﻦ‪.‬‬
‫اﻟﻜﻠﻤﺎت اﻟﺮﺋﻴﺴﻴﺔ‬
‫اﻟﺘﻜﺎﻣﻞ واﻟﻌﻤﻞ اﻟﻤﺸﺘﺮك‪ ،‬واﻟﻌﻤﻠﻴﺎت اﻟﺘﺠﺎرﻳﺔ‪ ،‬ﺑﺮوﺗﻮآﻮل اﻟﺘﻔﺎﻋﻞ‪،AUML ،‬‬
‫‪-π ،BPEL4WS‬ﺣﺴﺎب اﻟﺘﻔﺎﺿﻞ واﻟﺘﻜﺎﻣﻞ‪ - π،‬اﻟﻤﻨﻄﻖ‬
SOMMAIRE
Sommaire
Liste des figures
Liste des tableaux
Introduction générale
1. Contexte du travail de recherche …………………………………………………………. 1
2. Problématique et contribution de la thèse……………………………………………..….. 4
3. Organisation de la thèse…………………………………………………………………… 5
Chapitre I : Etat de l’art ; Concepts utilisés dans les e-services

1. Introduction ……………………………………………………………………... 7
2. Architectures Orientées Services (SOA) ………………………………………... 8
2.1 Architecture de service Web…………………………………………… 8
2.2 Standards des services Web …………………………………………… 10
2.2.1. Web Service Description Language (WSDL)………………… 10
2.2.2. Simple Object Access Protocol (SOAP)……………………… 11
2.2.3. Discovery and Integration (UDDI)…………………………… 11
3. Composition des services Web………………………………………………….. 12
3.1 Chorégraphie de services Web…………………………………………. 12
3.2 Orchestration de services Web ………………………………………… 13
3.3 Langages de description de la composition de services ……………….. 13
3.4 Business Process Execution Language (BPEL) ……………………….. 14
3.5 Discussion sur les langages de description de services Web ………….. 15
4. Systèmes multi-agent et interaction …………………………………………….. 16
4.1 Concept d’agent………………………………………………………… 16
4.2 Modes d’interaction…………………………………………………….. 17
4.3 Langages de communication entre agents………………………………. 17
4.4 Protocole d’interaction …………………………………………………. 18
5. Langage semi-formel de modélisation « Agent UML »………………………… 20
6. Aperçu des outils formels……………………………………………………….. 21
6.1 Travaux sur l’Abstract State Machines (ASM)………………………… 21
6.2 Travaux sur les systèmes états-transitions……………………………… 21
6.3 Travaux sur les réseaux de pétri………………………………………… 22
6.4 Travaux sur l’algèbre des processus……………………………………. 23
6.4.1. Utilisation du pi-calcul………………………………………. 24
6.4.2. Définitions…………………………………………………… 25
6.5 Logique temporelle pi-logique…………………………………………... 26
6.6 Synthèse ………………………………………………………………… 27
7. Quelques travaux reliés aux PI………………………………………………….. 27
8. Conclusion ………………………………………………………………………. 29
Chapitre II: Intégration et interopérabilité des services en ligne
1. Introduction………………………………………………………………………. 31
2. Intégration vs interopérabilité……………………………………………………. 32
2.1 Concept d’intégration …………………………………………………… 32
2.2 Concept d’interopérabilité……………………………………………….. 32
3. Principaux types d’interopérabilité………………………………………………. 33
3.1 Interopérabilité technique………………………………………………... 33
3.1.1 XML……………………………………………………………. 34
3.1.2 EAI……………………………………………………………… 34
3.2 Interopérabilité sémantique……………………………………………… 35
3.2.1 Ontologie……………………………………………………….. 36
3.2.2 Quelques projets sur l’interopérabilité sémantique…………….. 36
3.3 Interopérabilité organisationnelle………………………………………... 36
3.4 Discussion………………………………………………………………... 37
4. Différents aspects de l’interopérabilité…………………………………………... 38
5. Quelques travaux liés à l’interopérabilité et aux services……………………….. 40
5.1 Travaux antérieurs………………………………………………………. 40
5.2 Synthèse…………………………………………………………………. 41
6. Différents aspects d’intégration………………………………………………….. 42
6.1 Intégration de données ………………………………………………. 42
6.2 Intégration des applications …………………………………………. 42
6.3 Intégration des processus…………………………………………….. 43
7. Quelques approches pour l’intégration des applications………………………… 43
7.1. Workflow et serveurs d’application…………………………………. 43
7.2. Applications basées sur un échange des messages………………….. 44
7.3 Adaptateurs et connecteurs…………………………………………... 45
7.4. Synthèse……………………………………………………………... 46
8. Principaux champs d’intégration des applications………………………………. 46
9. Exemple de domaine d’application: le E-gouvernement………………………… 47
9.1. Définitions…………………………………………………………... 47
9.2. Interopérabilité dans le e-gouvernement……………………………. 48
10 Conclusion……………………………………………………………………….. 50
Chapitre III : Spécification d’un protocole d’interaction dans les

e-services
1. Introduction ……………………………………………………………………... 51
2. Motivation……………………………………………………………………….. 52
3. Fondements de notre approche………………………………………………….. 53
4. Définition du protocole d’interaction……………………………………………. 54
5. Etapes de transformation du protocole ………………………………………….. 55
6. Translation du diagramme d’interaction vers la spécification BPEL4WS……... 56
6.1. Messages échangés …………………………………………………… 59
6.2. Représentation des messages complexes……………………………… 59
6.2.1 Activité « switch »……………………………………………. 59
6.2.2. Activité « if »………………………………………………… 60
6.2.3. Constructeur « flow »………………………………………... 60
6.3. Services web et élément partenaire…………………………………….. 60
7. Passage de WS-BPEL vers le pi-calcul…………………………………………. 61
7.1. Processus nul…………………………………………………………….. 62
7.2. Réception………………………………………………………………… 62
7.3. Emission…………………………………………………………………. 62
7.4. Messages complexes…………………………………………………….. 62
7.4.1 Condition……………………………………………………….. 63
7.4.2. SWITCH……………………………………………………….. 63
7.4.3. Composition parallèle…………………………………………. 64
7.5. La boucle « while »……………………………………………………... 64
7.6. Séquence………………………………………………………………… 65
8. Spécifications des propriétés du PI……………………………………………… 66
9. Conclusion………………………………………………………………………. 68
Chapitre VI : Un couplage agent et web service pour l’intégration

et l’interopérabilité des applications basées sur les E-Services
1. Introduction ……………………………………………………………………... 69
2. Motivation……………………………………………………………………….. 71
3. Aperçu de l’approche proposée ………………………………………………… 72
4. Description des différents composants de notre architecture……………………. 75
4.1. Système font office……………………………………………………. 75
4.1.1. Composant « Agent utilisateur »……………………………. 75
4.1.2. Structure « base de données profil »………………………... 76
4.1.3. Structure «base de données de services »…………………… 76
4.2. Système back office…………………………………………………... 77
4.2.1. Structure et rôle des participants……………………………. 78
4.2.2. Structure de «Agent de protocole d’interaction»…………… 80
4.2.3. Bibliothèque des protocoles d’interaction………………….. 81
5. Comportement des agents ………………………………………………………. 82
5.1. Rôles des agents………………………………………………………. 82
5.2. Comportement des agents…………………………………………….. 82
6. Trace des interactions……………………………………………………………. 83
7. Modes de communication……………………………………………………….. 84
7.1. Communication inter-agents dans notre système……………………… 85
7.2. Les services……………………………………………………………. 86
8. Avantages de l’architecture proposée…………………………………………… 87
9. Conclusion………………………………………………………………………. 88
Chapitre V : Quelques aspects d’implémentation de l’étude de

cas : « E-Assurance »
1. Introduction ……………………………………………………………………... 89
2. Etude de cas……………………………………………………………………… 89
2.1. Enoncé ………………………………………………………………… 90
2.2. Développement de l’application « E-Assurance »…………………….. 90
2.2.1. Niveau front office………………………………………….. 91
2.2.2. Niveau back office………………………………………….. 91
3. Application de l’architecture proposée………………………………………….. 93
3.1. Back office…………………………………………………………….. 93
3.1.1. Spécification informelle : AUML vers BPEL………………. 93
3.1.2. Spécification formelle en pi-calcul…………………………. 96
3.1.3. Outil HAL…………………………………………………... 99
3.1.4. Spécification des propriétés du PI………………………….. 99
3.2. Le principe du modèle checking………………………………………... 101
3.3. Déploiement…………………………………………………………….. 102
3.3.1 Interopérabilité de plate-formes…………………………….. 102
3.3.2. Utilisation de la plate-forme JADE pour le développement
de l’architecture proposée………………………………….. 103
3.3.3. Simulation d’interaction entre agents de l’administration
publique et l’agent du protocole d’interaction……………..
104
3.3.4. Communication entre agents……………………………….. 107
3.4. Front office…………………………………………………………….. 108
3.5. Discussion……………………………………………………………... 109
4. Conclusion………………………………………………………………………. 110
Conclusion générale
1. Conclusion et bilan du travail………………………………………………………… 111
2. Perspectives envisagées……………………………………………………………… 112
Références bibliographiques……………………………………….……… 114

LISTE DES FIGURES
Figure.1.1 – Fonctionnement des services Web………… ………………………………….8
Figure. 1.2 – Architecture des services Web………………………………………………...9
Figure. 1.3 – Scénario d’utilisation des services Web………………………………………10
Figure .1.4 - Structure des messages SOAP………………………………………………...11
Figure. 1.5 – Chorégraphie de services Web ……………………………………………….12
Figure. 1.6 – Orchestration de services Web …………………………………….…………13
Figure. 1.7 – Structure d’un processus BPEL…………………………………….…………14
Figure. 1.8 – Différents types de branchements proposés par AUML…………….………..20
Figure.2.1 – Intégration par les processus métiers des applications de l’entreprise….……...35
Figure.2.2 – Champs d’intégration d’applications…………………………………….……..46
Figure.3.1 – Etapes de translation du protocole d’interaction………………………..............56
Figure.4.1 – Architecture du système proposé……………………………………………….74
Figure.4.2 – Structure de l’agent « Agent Utilisateur »……………………………..….……75
Figure.4.3 – Profil d’un agent participant………………………………………………..…..78
Figure.4.4 – Structure de l’agent participant……………………………………………...….80
Figure.4.5 – Structure de l’agent « Agent de protocole d’interaction »…………………...…81

Figure.4.6 – Structure d’un message XML dans FIPA-ACL………………………………86
Figure. 5.1 – Fonctionnement de le E-Assurance……………………………………….….90
Figure. 5.2 – Etapes de transformation du protocole d’interaction……………………....…92
Figure. 5.3– Etape de transformation de AUML vers BPEL4WS……………………….....94
Figure. 5.4 – Génération des partenaires en BPEL4WS………………………………...….95
Figure. 5.5 – Génération des variables en BPEL4WS…………………………………...…96
Figure. 5.6 – Exemple explicatif du processus de transformation……………………….....98
Figure. 5.7 – Le modèle checking……………………………………………………….....102
Figure. 5.8 – Spécification partielle du module communication…………………………..105
Figure. 5.9 – Extension de la classe « Agent » (CNAS et ASSC).…………………….…..105
Figure. 5.10 – Interface de l’agent Sniffer…………………………………………………106
Figure.5.11 – Interface de la CNAS……………………………………………………......107
Figure. 5.12 – Invocation de la méthode ‘’similarity’’…………………………………..…108
Figure. 5.13 – Code de la fonction ‘’similarity’’……………………………………….......108
LISTE DES TABLEAUX

Tableau.3.1 – Passage du diagramme d’interaction vers BPEL……………………………57
Tableau.4.1 – Comparaison entre service web et agent…………………………………….71

INTRODUCTION GENERALE
Les caractéristiques et les attentes des applications informatiques ont considérablement
changé ces dernières années, soulevant du même coup un nombre important de défis à relever.
Les concepteurs d’applications doivent maintenant faire face à la décentralisation, à la
distribution et au besoin d’interopérer et d’intégrer des systèmes hétérogènes. De plus, ils
doivent être en mesure de fournir des solutions robustes et capables de s’adapter dans des
environnements qui peuvent être aussi imprévisibles et versatiles que l’Internet. Le succès de
ce dernier concept à donner naissance au nouveau modèle Electronic Service (e-service). Ce
dernier, est un moyen pour accueillir des services d’une manière électronique via Internet.
Face à ces nouveaux enjeux, les techniques classiques ne parviennent qu’à proposer des
réponses limitées.
1. Contexte du travail de recherche
Depuis quelques années, il est devenu naturel pour les organisations d’utiliser et de faire
coexister des systèmes d’informations, des processus différents ou des services. Cela permet à
ces organisations de mener à bien des projets communs, ou de réaliser des coopérations afin
de pouvoir continuer à progresser.
Dans ce contexte, l’interopérabilité et l’intégration des applications sont devenues de plus en
plus importantes afin de pouvoir satisfaire à la fois les besoins des citoyens et ceux des
organisations, tout en rentabilisant les investissements consentis dans des systèmes
généralement assez coûteux.
Les organisations doivent à la fois connecter les nombreuses applications hétérogènes
existantes, exploiter des données issues de systèmes d’information différents et définir de
nouveaux processus tout en garantissant à terme la cohérence du système [1].
Les architectures orientées services (SOA)1 [1] constituent une réponse aux problématiques
que rencontrent les développeurs en termes de description, de réutilisabilité, d’interopérabilité
et de réduction de couplage entre les différents systèmes (services) qui implémentent des
fonctionnalités, et issues en général d’applications complexes, en cachant les détails
d’implantation.
Dans notre travail, nous nous intéressons au cas des SOA basées sur les services Web [1]. Un
des apports principaux de ces architectures est la possibilité d’intégrer des services
préexistants et indépendants pour construire de nouveaux services avec de nouvelles
fonctionnalités.
Les services Web semblent donc être bien adaptés aux problèmes sous tendus par l’intégration
des processus métiers. Ils permettent en effet une intégration centrée sur les services, où les
1. Plus connues sous le nom en anglais SOA pour Service Oriented Architecture
1
fonctions automatiques sont mises à la disposition de tous les utilisateurs éventuels, quelles
que soient la technologie et les spécifications d’interfaces qu’ils utilisent [3].
Par ailleurs, certaines propriétés fondamentales telles que le passage à l’échelle (la
scalabilité), l'interopérabilité et la réutilisabilité sont nécessaires dans les SI (Système
d’Information). Cependant, ces propriétés sont difficiles à mettre en œuvre lorsque nous
utilisons des architectures traditionnelles. Pour satisfaire ces propriétés, le paradigme agent
[25] a reçu beaucoup d'intérêt. Sans doute, les Systèmes Multi-Agents (SMA) semblent être
les candidats les plus encourageants quant au développement des SI.
La combinaison des deux paradigmes agent et service Web semble être un moyen prometteur
pour la construction d’un processus d’interopérabilité et d’intégration des processus métiers.
Architectures orientées services SOA
Actuellement, l’émergence d’architectures logicielles fondées sur les services visent à mettre
en place des processus métier performants ainsi que des systèmes d’information constitués de
services applicatifs indépendants et interconnectés. Ces architectures sont connues sous le
nom d’Architectures Orientées Services (SOA) [1]. Elles facilitent l’exposition,
l’interconnexion et la réutilisation d’applications à base de services. Ainsi, de nouveaux
services peuvent être créés à partir d’une infrastructure informatique de systèmes déjà
existante. Ces derniers peuvent être utilisés par des processus métier ou par des clients dans
différentes applications.
Les services Web sont la réalisation la plus importante d’une architecture SOA. Ce sont des
applications auto-descriptives, modulaires et faiblement couplées fournissant un modèle
simple de programmation et de déploiement d’applications. Ils reposent principalement sur
des technologies basées sur SOAP [2] pour la structure et le contenu de messages échangés
entre services, WSDL [3] pour la description des services, UDDI [6] pour la découverte des
services et BPEL4WS2 [7] pour leur composition.
Toutefois, ces approches présentent plusieurs limites dont nous présentons les plus récurrentes
[8][9] :
– Les services web sont passifs jusqu’à ce qu’ils soient invoqués ;
– Un service web a seulement connaissance de lui-même, mais pas celle de ses applications
ou ses utilisateurs clients ;
– Un service web n’est pas adaptable, et il n’est pas capable de bénéficier des nouvelles
capacités de l’environnement afin d’apporter des services améliorés.
2. Business Process Execution Language for Web Services
2

L’autonomie, l’adaptation et la coopération, points faibles des services web, sont par ailleurs
des domaines qui ont largement été explorés dans des travaux relatifs aux systèmes multi-
agents.
A cet effet, nous mettrons en exergue les systèmes mutli-agents, en rapprochant l’intégration
des processus métiers de l’interaction multi-agents.
Les systèmes multi-agents
Les systèmes multi-agents constituent aujourd’hui une nouvelle technologie pour la

conception et le contrôle de systèmes complexes. Un système multi-agents est un système
composé d’entités logicielles ou matérielles autonomes appelées agents.
L’approche multi-agents repose sur plusieurs théories et concepts qui trouvent leurs origines
dans plusieurs disciplines tels que la sociologie, la psychologie, les systèmes répartis, le génie
logiciel.
En effet, Demazeau définit le système multi-agents selon cinq aspects [152] : l’agent,
l’environnement, l’interaction, l’organisation et l’utilisateur. L’interaction est ainsi un des
aspects clés de ces systèmes. Elle offre un moyen pour assurer la coopération entre agents.
Sans interaction (ou communication), l’agent n’est qu’un individu isolé, sourd et muet,
renfermé sur sa boucle perception-délibération-action [25].
Nous nous penchons sur les systèmes multi-agents dont l’interaction est directe, régie par les
protocoles d’interaction. Ce dernier, est un enchaînement prédéfini de messages.
Les protocoles d’interaction sont introduits dans les systèmes multi-agents dans le but de
faciliter la spécification et l’implémentation de l’interaction entre les agents. D’après la
définition de FIPA3, un protocole d’interaction est un pattern commun de communication.
En effet, les protocoles d’interaction dans les SMA s’adaptent bien à la modélisation des
problématiques (de répartition, d’ouverture, de flexibilité et de coordination des processus,
etc.) sous-tendues par l’intégration d’applications.
Dans ce type d’applications, les protocoles sont donc identifiables et récurrents. Il est alors
utile de les isoler afin de bien les étudier, les modéliser et les implémenter comme des entités
à part entière pour permettre leur partage, leur recherche et leur invocation.
Dans notre thèse, nous nous intéressons à l’intégration consistant à coordonner des processus
métiers afin d’atteindre un objectif commun. Nous spécifions des propriétés et des protocoles
d’interaction SMA, vérifier leurs comportements et de les adapter pour intégrer plusieurs
applications.
3. Plus connues sous le nom en anglais Foundation of Intelligent Physical Agents
3

2. Problématique et contribution de la thèse
Le problème principal qui se pose est de faire interopérer et coopérer des systèmes déjà
existants et qui sont toujours opérationnels. Le but de notre travail est donc de prévoir une
couche au-dessus de ces systèmes afin qu’ils puissent coopérer et interopérer de façon
efficace.
En effet, il n’est pas sûr qu’une application basée sur des services distants et interconnectés
par des réseaux, aboutira par la bonne intégration des processus à une application correcte.
Pour cela, il est nécessaire d’avoir une sémantique opérationnelle précise des langages de
description comportementale de ces processus.
Pour faire face à ces problèmes, les services Web fournissent une solution prometteuse. Ils
consistent à exposer sur le réseau d’Internet, une ou plusieurs applications. Ces services
peuvent proposer des fonctions très simples (du type requête/réponse) ou un ensemble
complet d’outils, permettant d’aller jusqu’à l’intégration des services pour proposer une
application complète.
La combinaison des deux paradigmes agent et service Web semble être un moyen prometteur
pour la construction d’un processus d’intégration et d’interopérabilité des processus métiers.
Nous proposons une nouvelle approche qui permet à la fois l'intégration et la collaboration de
modules autonomes et distribués des processus métiers. A cet effet, nous définissons un
protocole d'interaction (PI)4. Comme nous l’avons déjà défini plus haut, ce dernier, est un
ensemble de règles communicatives et de contraintes liées à un ensemble fini de rôles qui
vont être joués par des agents [25]. Il permet à ces derniers d'avoir des conversations sous
forme d'échanges structurés de messages [28]. Les PI étaient le premier défi de la conception
du système multi-agents [25].
La communauté de l'agent a répondu en développant la notation Agent UML (AUML) [36].
Un profil UML dédié à des agents qui tentent de simplifier la transition de génie logiciel à
l'ingénierie des systèmes multi-agents. En outre, BPEL4WS est un standard de facto pour
décrire l’Intégration des processus métiers (BPI 5) comme la composition des services web.
Afin d'augmenter la fiabilité des protocoles d’interaction au moment de la conception, nous
proposons une approche pour la spécification et la validation de la BPI. Dans notre cas, il est
modélisé à l'aide de AUML et est spécifié avec BPEL4WS. Pour une meilleure interactivité,
la communication entre les processus métiers devrait être réglementée de façon appropriée. Le
PI fournit un terrain formel pour permettre ce règlement. Cependant, l'élaboration de
protocoles d’interaction qui seront exécutés par des partenaires autonomes est difficile.
Semblables à des protocoles dans les systèmes traditionnels, les PI dans les milieux ouverts et
basés sur le Web doivent être spécifiés rigoureusement afin que les partenaires puissent
4. Dans la suite du document, nous utilisons l’acronyme PI pour Protocole d’Interaction

4
5. Plus connue sous le nom en anglais BPI pour Business Process Integration

interagir avec succès. Cela soulève le problème évident de vérifier que l'interaction des
processus métiers respectent le PI.
Bien que certains de ces langages soient considérés comme des standards, l’absence de
sémantique formelle et la possibilité d’interprétations ambiguës des documents décrivant ces
standards, constituent un frein à leur utilisation, à leur généralisation, et compromettent
l’interopérabilité. De plus, ces langages n’offrent aucune possibilité pour décrire des
exigences que le service doit assurer, et les outils associés ne permettent pas de garantir à
priori que les processus métiers intégrés obtenus se comportent conformément à des
exigences.
Afin de palier cette lacune, nous proposons une sémantique opérationnelle pour notre modèle.
Cette sémantique est basée sur des règles de transformation garantissant le respect de la
cohérence du système.
Le modèle formel retenu pour la représentation du comportement observable des processus

métiers est le formalisme pi-calcul [72] de l’algèbre des processus.
Aussi, nous spécifions des propriétés des protocoles d’interaction SMA, vérifier leurs
comportements et les adapter pour intégrer plusieurs applications des e-services.
Une fois le protocole d’interaction est conçu, nous allons l’exploiter dans une architecture
basée agents qui permet l’interopérabilité et l’intégration des processus métiers. Cette
architecture est composée de deux parties principales : le back office et le front office.
La première partie doit s'assurer de la collaboration des systèmes d'information dans le back-
office. Ces participants offrent des services gérés par des agents intelligents qui ont besoin de
travailler sur la base d'un protocole d'interaction. Chaque agent gère plusieurs services Web.
Dans cette approche, les différents agents interagissent en envoyant des messages et en
utilisant un langage de communication d'un haut niveau (FIPA-ACL) [28]. Le PI sera utilisé
par un agent intermédiaire nommé «Agent de protocole d'interaction » qui va coopérer avec
d'autres agents du système. Ce protocole est publié et partagé par cet agent pour une
éventuelle réutilisation, d'adopter le processus d'intégration et de le gérer efficacement à
chacune des étapes de la composition et de la surveillance. La deuxième partie de notre
architecture est le front-office. Le citoyen peut directement atteindre le portail via Internet et
peut choisir le service dont il a besoin. Il activera automatiquement l’agent «user agent». Le
type de service choisi lui permettra d'être connecté directement avec la partie back-office.
3. Organisation de la thèse
Ce document est organisé en cinq chapitres dont les deux premiers concernant l’état de l’art
des thèmes de recherche abordés dans cette thèse.
5

Le premier chapitre présente les caractéristiques des architectures orientées services, la

technologie de services Web et le concept de composition de services Web. Ce chapitre
discute des problèmes existants dans les langages de description de services Web et de leur
influence sur leur analyse et de leur composition. Nous présentons par la suite quelques
concepts de l’approche agent et ses apports dans la mise en œuvre de l’interopérabilité et
l’intégration d’applications. Il présente également un panorama de méthodes formelles. Puis,
nous dressons un bilan des différentes insuffisances constatées. Le formalisme pi-calcul
utilisé dans l’approche de vérification et de validation formelles d’intégration des processus
métiers a été présenté.
Le deuxième chapitre expose les différentes formes trouvées dans la littérature et les
approches existantes pour l’interopérabilité et l’intégration des processus métiers. Nous y
analysons les avantages et les inconvénients de chacune de ces approches par rapport à la
problématique posée et aux objectifs fixés dans la thèse. De même, nous présentons les
différentes techniques qui sont mises en œuvre pour favoriser de manière générale,
l’intégration et l’interopérabilité dans les systèmes d'information. Par la suite, nous présentons
le domaine d’application qui est le e-gouvernement et l’importance du concept
d’interopérabilité dans ce domaine.
Dans le troisième chapitre nous proposons une «approche orientée interaction» pour la
modélisation de notre approche. Cette dernière permet de pallier les limites des techniques de
l’intégration d’applications par coordination des processus, car ils apportent des solutions et
des modèles pour tenir compte de plusieurs contraintes telles que la répartition des
partenaires, l’ouverture et la flexibilité de leur environnement.
Le quatrième chapitre est consacré à notre deuxième contribution qui consiste en la
proposition d’une architecture basée agent pour le e-service. Il présente les deux parties de
notre architecture. La première partie est consacrée à la spécification en termes de structures
d’agents, de comportements des agents, ainsi que la communication inter-agents. La
deuxième partie concerne la connexion au portail en activant un ensemble d’agents.
Le cinquième chapitre présente une étude de cas sur lequel nous appliquons les différentes
étapes du processus de modélisation pour aboutir à un PI cohérent. Ensuite, nous présentons
la validation de l’architecture proposée dans le domaine de le E-gouvernement. Cette étude de
cas est conclue par une simulation faite dans l’environnement JADE en expliquant comment
nous pouvons réaliser et implémenter les concepts de base (spécifications d’agents,
interaction..).
Enfin, nous terminerons notre mémoire par un bilan du travail de recherche effectué durant
cette thèse en donnant les conclusions et quelques perspectives envisagées pour la poursuite
de cette démarche.
6

1
Etat de l’art :
Concepts utilisés dans les e-services
1. Introduction
Les dernières décennies ont été marquées par le développement rapide des systèmes
d’information distribués, et tout particulièrement par la diffusion de l’accès à Internet. Cette
évolution du monde informatique a entraîné le développement de nouveaux paradigmes
d’interaction entre applications et l’émergence du nouveau paradigme E-Service (Electronic
Service). Ce dernier est moyen pour accueillir des services d’une manière électronique via
Internet. Le paradigme e-services, s'appuyé sur une architecture orientée services et met
l'accent sur la création d'environnements de services fiables grâce aux relations solides entre
les participants.
Cependant, dans ce chapitre nous essayons de dresser un état de l’art sur les différents
concepts et outils liés aux e-services.
Aussi, nous résumons un ensemble de travaux de recherche autour de la modélisation et la
vérification formelles dans le domaine des services web et de l’interaction dans les systèmes
multi-agents. Il comprend deux parties principales. La première partie est consacrée à la
description des architectures orientées services et des systèmes multi-agents ainsi que l’utilité
des protocoles d’interaction. La deuxième partie présente les différentes approches et
techniques de modélisation et de vérification formelles inspirées de la littérature. L’utilisation
des méthodes formelles pour la modélisation de la composition de services Web est surtout
motivée par l’absence d’une sémantique formelle et de l’existence d’ambiguïtés dans les
langages dédiés à la description de Workflows de services. Les approches citées ont été
réalisées à l’aide du langage BPEL, considéré comme le standard de description de
l’intégration de services Web.
7
Etat de l’art : Concepts utilisés dans les e-services
2. Architecture Orientées Services (SOA)
Avec l’avènement du Web, les clients ont pratiquement un accès direct aux informations
fournies par les producteurs
Figure.1.1 – Fonctionnement des services Web
Chaque fournisseur propose, à ses clients, différentes formes et divers moyens de consultation
des données. En conséquence, la même application peut être mise en œuvre sur le Web par
plusieurs services chargés de l’adaptation et de la présentation de l’information au client. La
figure 1.1 résume le fonctionnement d’une architecture orientée services. Une entreprise
propose ses offres sous forme d’un ensemble de services Web, représentant des interfaces
publiques par des opérations qui correspondent aux fonctionnalités offertes par l’entreprise.
Dans la partie qui suit, nous expliquons d’une manière brève la technologie service web.
2.1. Architecture de Service Web
L’objectif des technologies basées sur les services Web est de fournir un support naturel pour
des plateformes d’invocation indépendantes par une interface simple et comprise, conçue dans
le but d’être réutilisée. L’aspect clé de cette technologie est l’utilisation de langages et de
protocoles standardisés, conçus dans le but d’améliorer l’intégration entre les parties
coopérantes. C’est un des avantages qui nous a incité à utiliser cet aspect dans notre thèse.
Ces standards couvrent pratiquement tous les aspects du développement et de configuration,
tels que la représentation et l’échange des données, la description des propriétés
fonctionnelles et non fonctionnelles d’un service, d’agrégation, de coordination et de gestion
d’un ensemble de services.
8
Figure. 1.2 – Architecture des services Web [1]
La figure 1.2, représente une pile de standards constituant l’architecture de services Web [1]
tels que : Simple Object Access Protocol (SOAP, [2]), Web Service Description Language
(WSDL, [3]). Lorsqu’il est nécessaire de décrire l’évolution de l’état interne du service ou de
spécifier un protocole d’interaction que nous devons suivre pour utiliser correctement les
fonctionnalités d’un service, le modèle du service est complété par une description du
comportement. Ce comportement peut être spécifié par le standard BPEL (Business Process
Execution Language, [4]), un langage utilisé pour la description et l’exécution des workflows
de services. Ce langage sera exploité dans le troisième chapitre pour décrire notre modèle
proposé.
Les trois acteurs essentiels participant à une communication service Web sont : le fournisseur
du service, le client et l’annuaire de services (voir figure 3).
– Le fournisseur du service se charge de la description des messages manipulés et des profils
des fonctionnalités offertes par le service. Il doit publier le service dans un annuaire afin qu’il
puisse être trouvé par les clients.
– Le client est une application qui cherche, localise et invoque le service.
– L’annuaire de services fournit des informations sur la description et la localisation des
services Web.
9
Figure. 1.3 – Scénario d’utilisation des services Web [1]
L’invocation d’un service Web [1] se fait selon le scénario décrit sur la figure 1.3. Un service
est implémenté, décrit et publié par un fournisseur de services dans un annuaire de services
(1). Un client interroge l’annuaire en utilisant les outils de recherche et de découverte fournis
par l’annuaire afin de trouver un service qui implémente les fonctionnalités recherchées (2,3).
Une fois qu’un service approprié est trouvé, le client se connecte au fournisseur, obtient la
description du service (4,5), et invoque les opérations du service (6). Le service répond aux
requêtes envoyées par le client (7). Tout ce scénario est basé sur les différents standards que
nous décrivons dans la section suivante.
2.2. Standards des services Web
Dans cette section, nous présentons les différents standards utilisés dans l’architecture de
service Web, à savoir, WSDL pour la description des services Web, SOAP pour le transport
des messages échangés entre les services et UDDI pour la publication des descriptions de
services.
2.2.1. Web Service Description Language (WSDL)
Le langage WSDL [3] est un standard W3C basé sur une syntaxe XML [5]. Il décrit une
interface publique du service Web en définissant l’adresse du service, son identité, les
opérations qui peuvent être invoquées par les clients, les paramètres des opérations ainsi que
leurs types. WSDL décrit les fonctionnalités offertes par un service Web avec des opérations
définissant un échange de messages. Un ensemble d’opérations sont enveloppées dans un port
10
définit comme un point final lié à un protocole de transport tel que (SOAP, HTTP, SMTP,
MIME, etc.) véhiculant les messages échangés entre le service Web et le client.
2.2.2. Simple Object Access Protocol (SOAP)
SOAP [2] est le standard adopté par W3C pour la description et la transmission des messages
entre deux points distants. Le transfert se fait le plus souvent à l’aide du protocole HTTP. Des
protocoles tels que SMTP, FTP, JMS ou IIOP peuvent être également utilisés comme
protocoles de transport. SOAP utilise une syntaxe XML pour définir la structure des messages
échangés par les services web. Les messages sont enveloppés dans des requêtes http
classiques (GET, POST). Cette requête comporte un en-tête et un corps contenant le message
SOAP envoyé. Un message SOAP se compose de trois éléments à savoir une enveloppe, un
en-tête et un corps (voir figure 1.4).
Figure .1.4 - Structure des messages SOAP
2.2.3. Discovery and Integration (UDDI)
A l’instar de toutes les ressources disponibles sur le Web, un service Web serait pratiquement
impossible à localiser sans passer par des outils de recherche. Les annuaires de services Web
représentent des bases de services où les fournisseurs peuvent publier et enregistrer des
informations sur leurs services et leurs profils. Les annuaires des services Web peuvent être
implémentés par des services Web accessibles par des applications informatiques. Ces
annuaires fournissent des informations sur les services Web disponibles dans l’annuaire
correspondant à la requête de recherche du client.
UDDI [6] est un standard OASIS permettant de fournir une méthode de publication et de
découverte d’informations sur les services Web. UDDI permet de publier et de rendre visible
un service Web développé et fournit par une organisation en décrivant des informations sur la
localisation de sa description et ses méthodes d’invocation.
11
Les services Web sont apparus rapidement comme l’approche la plus pratique pour
l’intégration d’un grand nombre de clients, de fournisseurs et d’applications commerciales.
Bien que de nombreuses entreprises ont commencé à déployer des services Web individuels,
la valeur réelle viendra lorsque les entreprises pourront connecter leurs services, créant ainsi
un nouveau service avec une plus grande valeur ajoutée. La possibilité de créer de nouveaux
services Web en combinant des services web pré-existants reste l’un des apports les plus
importants des architectures orientées services.
3. Composition des services Web
La composition des services Web est traditionnellement décrite à l’aide des termes
orchestration et chorégraphie [7].
3.1. Chorégraphie de services Web
La chorégraphie de services Web décrit, d’un point de vue global, une collaboration de
l’ensemble des services Web participants, qui interagissent afin d’atteindre un but commun.
Elle modélise la séquence des échanges de messages entre services web et définit les
conditions dans lesquelles ces messages sont échangés alors qu’un procédé métier est exécuté
de manière centralisé. La chorégraphie suit un processus de développement top-down (de haut
en bas) où la spécification globale du service Web composé est en cours d’élaboration. Ce
modèle global peut être considéré comme un modèle du comportement composé auquel les
implémentations des services Web doivent se conformer (voir figure 1.5).
Figure. 1.5 – Chorégraphie de services Web
12
3.2. Orchestration de services Web
L’orchestration de services Web décrit le protocole défini par un service participant

particulier à une composition de services Web. Elle décrit la manière dans laquelle les
services Web peuvent interagir ensemble au niveau des messages, incluant la logique métier
et l’ordre d’exécution des interactions (ordonnanceur ou séquenceur). L’orchestration suit un
processus de développement bottom-up (de bas en haut) où la composition est définie à partir
d’un ensemble de spécifications locales. L’orchestration fait souvent référence à un processus
exécutable qui interagit avec d’autres services Web dans le but d’accomplir les objectifs de
l’orchestrateur (voir figure 1.6).
Figure. 1.6 – Orchestration de services Web
Une différence importante entre l’orchestration et la chorégraphie est que l’orchestration offre
une vision locale et centralisée, c’est-à-dire, le procédé est toujours sous le contrôle d’un des
partenaires métier. En revanche, la chorégraphie offre une vision globale et plus collaborative
de la coordination. Elle décrit le rôle que joue chaque participant impliqué dans l’application
[8].
3.3. Langages de description de la composition de services
Les langages de description de compositions de services Web sont basés sur une syntaxe
XML et sont généralement décrits à l’aide d’un schéma XSD (XML Schema Definition).
Nous trouvons deux catégories de langages de description de services Web composés. La
première catégorie concerne les langages de description de services sémantiques. Nous citons
les langages OWL-S (Semantic Web Ontology Language) [9] et WSMO (Web Service
modeling language) [10] qui sont les plus connus. Ces derniers permettent de décrire une
composition de services Web sous forme d’un processus orchestrant des activités. Chaque
activité peut avoir des informations sémantiques, provenant d’une ontologie, sur sa
13
fonctionnalité, son rôle et les données qu’elle manipule. Une activité peut avoir comme rôle
l’invocation d’un service Web partenaire. Un lien vers le fichier WSDL décrivant ce service
est défini.
La deuxième catégorie concerne les langages de description de services sans références
sémantiques. Dans cette catégorie il existe des langages dédiés à la description de la
chorégraphie comme le standard CDL (Choreograhy Description Language) [11], des
langages dédiés à la description de l’orchestration de services comme le standard BPEL [4]
qui est utilisé dans notre proposition et le langage XPDL (XML Process Definition
Language)[12], ou des langages dédiés aux deux comme BPMN (Business Process Modeling
Notation)[13]. Malgré les différences syntaxiques existantes, ces langages s’accordent sur les
constructeurs offerts et sur la capacité à traiter certains problèmes [14], [15].
3.4. Business Process Execution Language (BPEL)
Le langage BPEL ([4], [16]) est le standard OASIS de description de Workflow de services et
de la composition de services Web. Dans son évolution, BPEL remplace les précédentes
spécifications XLANG de Microsoft et WSFL (Web Services Flow Language) d’IBM. Depuis
2003, OASIS s’occupe toujours de la standardisation de BPEL. La dernière version (version
2.0) a été publiée en 2007 [4]. BPEL est un langage basé sur une syntaxe XML modélisant un
processus métier par une composition d’un ensemble de services Web élémentaires. Chaque
processus BPEL peut être considéré également comme un service Web. La spécification
BPEL utilise des normes W3C : WSDL [3] pour la description des services Web partenaires,
XML Schéma [2] pour la définition des structures de données, et XPath (XML Path) [17]
pour la récupération d’éléments XML. Cinq des concepts les plus importants de BPEL sont
présentés sur la figure 1.7, à savoir, partnerLinks, variables, simple activities, structured
activities, et handlers.
<process name=... >

...
<import ...> importation des déclarations des services Web partenaires</import>*
<partnerLinks>?
<partnerLink name=.../>+ déclaration des liens vers les services Web partenaires
</partnerLinks>
...
<variables>?
<variable name=.../>+ les variables de l’état interne du processus BPEL
</variables>
...
14
<faultHandlers>? déclaration du gestionnaire d’erreurs internes</faultHandlers>

<eventHandlers>? déclaration du gestionnaire d’événements </eventHandlers>
Activity spécification du comportement interne du processus BPEL
</process>
Figure. 1.7 – Structure d’un processus BPEL.
BPEL permet de spécifier deux types de processus :

9 processus abstrait: Il représente une vue ou une abstraction du comportement d’un
processus BPEL. Il permet de cacher une partie du processus BPEL à déployer. Il
n’est pas possible de l’exécuter.
9 processus exécutable: Il détaille le comportement d’un processus BPEL en
spécifiant l’ordre d’exécution des partenaires et les messages échangés ainsi que le
traitement des erreurs et des exceptions. Il peut être déployé et exécuté.
3.5. Discussion sur les langages de description de services Web
Plusieurs langages permettant de spécifier la composition de services Web existent dans la

littérature BPEL, BPMN et XPDL sont les plus connus dans la catégorie de l’orchestration de
services alors que CDL est le standard utilisé pour la description de la chorégraphie. La
plupart de ces langages se basent sur une syntaxe XML et sont présentés par un schéma XML
(XSD).
Les documents de spécification de ces langages expliquent la sémantique des schémas XML
d’une manière informelle et se basent sur le langage naturel (Anglais) pour la définition des
différents éléments et constructeurs offerts par ces langages [4]. Des incohérences, des
incomplétudes et des ambiguïtés existent dans l’interprétation de ces constructeurs [18]. Des
erreurs de spécification du processus correspondant au comportement du service Web
composé peuvent apparaître lors de la conception.
Les différents outils associés à ces langages, permettent de visualiser graphiquement la
spécification et/ou d’exécuter le processus décrit en offrant une sémantique opérationnelle.
Par contre, il n’y a aucun moyen de vérifier à priori le comportement du processus obtenu.
Dans le cas de la composition des services Web, il est important d’avoir une idée sur le
comportement du service Web composé obtenu, et surtout de s’assurer de l’absence des
erreurs de spécification avant le déploiement. De plus, la plupart de ces langages n’offrent pas
de moyen syntaxique pour exprimer et vérifier formellement des propriétés
comportementales, fonctionnelles ou non-fonctionnelles sur le service Web composé obtenu.
Le recours à l’utilisation des méthodes formelles devient une nécessité [19], [20].
15
Dans notre cas, nous avons choisi d’utiliser la méthode formelle basée sur l’algèbre des
processus que nous présentons dans la section de ce même chapitre.
L’autonomie, l’adaptation et la coopération, points faibles des services Web, sont par ailleurs
des mécanismes qui ont largement été explorés dans plusieurs travaux de recherche effectués
dans le domaine des systèmes multi-agents. Plusieurs études décrivent à ce propos la
pertinence de la combinaison des technologies agent et services Web [22].
Dans ce qui suit, nous faisons une brève présentation des systèmes multi-agents et du
mécanisme d’interaction qu’ils intègrent. Nous rapprochons les domaines de l’intégration
d’applications et de la coordination multi-agents.
4. Système multi-agent et interaction
Aujourd'hui, la plupart des applications de l’e-service nécessitent de distribuer des tâches

entre des "entités" autonomes qui interagissent continuellement entre eux afin d'atteindre leurs
objectifs d'une manière optimale. Puisque les approches classiques soient en général
monolithiques et leur concept d'intelligence soit centralisé, le développement des applications
basées sur les e-services actuelles s’oriente fortement vers le paradigme agent [23].
4.1. Concept d’agent
Plusieurs définitions de l'agent logiciel existent dans la littérature. En effet, Khezami et al.,
[23] a défini l'agent comme un objet informatique (au sens des langages objet) dont le
comportement peut être décrit par un script qui dispose de ses propres moyens de calcul. Un
agent doit nécessairement être motivé par un but à atteindre, sinon son existence dans son
environnement n'aurait pas de sens. Il peut percevoir l'environnement mais peut n'en posséder
qu'une représentation partielle, et parfois même aucune. Il peut communiquer avec les autres
agents de son environnement et doit avoir des compétences qui lui permettent d'atteindre ses
objectifs. Selon Maamar et al. [24], un agent est un morceau de logiciel qui agit d'une façon
autonome pour entreprendre des charges au nom des utilisateurs. Les auteurs affirment que la
conception de beaucoup d'agents logiciels est basée sur le fait que les utilisateurs doivent
seulement indiquer un but à niveau élevé au lieu de publier des instructions explicites, et
laissant les décisions à l'agent. Ce dernier, montre un certain nombre de dispositifs qui le
rendent différent des autres composants traditionnels. Les principales caractéristiques des
agents sont [24,25] : modularité, autonomie, interaction, coordination, personnalisation,
intelligence, émergence.
16
4.2. Modes d’interaction
Le simple fait de placer un ensemble d’agents dans un même environnement n’est pas
suffisant pour définir un SMA. Les différents agents doivent être en mesure d’interagir et de
se comprendre mutuellement afin de pouvoir se coordonner et éventuellement coopérer.
L’étude des mécanismes d’interaction est donc primordiale dans la conception d’un SMA.
Pour citer Ferber [25] : “Pour un agent, interagir avec un autre constitue à la fois la source de
sa puissance et l’origine de ses problèmes. C’est en effet parce qu’ils coopèrent que des
agents peuvent accomplir plus que la somme de leurs actions, mais c’est aussi à cause de leur
multitude qu’ils doivent coordonner leurs actions et résoudre des conflits.”. Morin [26] a
donné la définition suivante de l’interaction: “ [. . .] Les interactions sont des actions
réciproques modifiant le comportement ou la nature des éléments, corps, objets, phénomènes
en présence ou en influence.” [27].
L’interaction entre les agents peut apparaître sous différentes formes comme la collaboration
quand il s’agit de répartir des tâches entre un ensemble d’agents, la coordination quand il
s’agit d’organiser les actions de différents agents pour atteindre un but collectif c’est le cas de
notre protocole d’interaction proposé, ou encore la négociation quand il s’agit de résoudre des
conflits entre les agents.
Nous distinguons généralement deux modes d’interaction : le mode direct et le mode indirect.
Usuellement cette distinction est décrite dans la littérature relativement à l’environnement :
l’interaction indirecte est traitée comme une interaction entre les agents et l’environnement
alors que l’interaction directe correspond à des échanges entre agents sans passer par
l’environnement. Dans notre architecture, nous avons opté pour le mode direct.
Nous distinguons bien l’interaction directe de l’interaction indirecte, mais en utilisant un
critère différent de l’environnement. L’interaction directe correspond à une interaction dirigée
comme dans le cas d’envoi de messages. Un agent exploite ses capacités dans
l’environnement pour émettre un message vers un ou plusieurs agents désignés dans
l’environnement.
L’interaction indirecte quant à elle n’est pas dirigée. Elle est au contraire caractérisée par un
découplage du nom, du temps et de l’espace [27]. Ainsi pour interagir de manière indirecte,
les agents n’ont pas besoin de connaître explicitement les autres agents. Ils n’ont besoin ni
d’être situés au même endroit, ni de co-exister en même temps.
4.3. Langages de communication entre agents
Les langages de communication agent, souvent désignés par l’acronyme ACL (Agent
Communication Language), ont retenu une grande attention de la part de la communauté
multi-agents. La communication est indispensable entre les agents, sans quoi ils se trouvent
17
tous être isolés et incapables de se coordonner pour réaliser des tâches collectivement et
résoudre les différents conflits qui proviennent de la concurrence de leurs activités.
A la base de toutes les théories de la communication se trouve celle de Shannon [28]. Dans
cette théorie, l’acte de communication correspond à l’envoi d’information par un émetteur
vers un destinataire au travers d’un canal de communication. L’information transmise est
encodée dans un langage à l’émission et décodée à la réception.
La théorie de Shannon a établi un support pour les aspects techniques de la communication
mais elle n’aborde pas les autres aspects de la communication. Par la suite, Austin [29] puis
Searle [30] ont développé la théorie des actes du langage qui a influencé tous les travaux
suivants sur la communication.
La théorie des actes du langage considère trois aspects dans la communication :
1. L’acte locutoire : comment le message est formulé.
2. L’acte illocutoire : ce que cela signifie pour l’émetteur ou comment cela est compris par le
destinataire.
3. L’acte perlocutoire : l’effet produit par l’acte illocutoire sur le destinataire.
Les actes de langages ont été classés suivant le performatif. Searle et Vanderveken en
distinguent cinq : assertif, directif, promissif, expressif et déclaratif. D’autres travaux
considèrent des performatifs supplémentaires.
La théorie des actes du langage a fourni le support pour la définition de la sémantique d’un
langage en termes des états mentaux des agents [31]. Le langage FIPA-ACL [32] est l’héritier
de cette approche de définition de la sémantique : chaque performatif est associé à des pré-
conditions et des post-conditions sur les états mentaux des agents qui communiquent.
Par ailleurs les travaux sur les ACL distinguent trois niveaux dans la structure d’un message
[33, 34] :
1. Le niveau du contenu qui est décrit dans un langage de contenu comme KIF, PROLOG ou
FIPA-SL.
2. Le niveau du message qui est définit par le performatif du message, une ontologie, le
langage, etc.
3. Le niveau de la communication qui permet de décrire les méta-données relatives à la
communication telles que l’émetteur du message, le destinataire, le protocole utilisé, etc.
Nous passons maintenant à la description des protocoles d’interaction représentant un élément
clé de notre démarche et architecture.
4.4. Protocole d’interaction
Les protocoles d’interaction [25] ont été proposés pour déterminer la structure des interactions
entre les agents et ainsi faciliter leur coordination. Un protocole d’interaction spécifie des
18
règles qui doivent être respectées par les agents durant une conversation, et définit ainsi pour
chaque étape les types de messages qui peuvent être envoyés.
En suivant un protocole, un agent interprète les messages d’une conversation un par un, en
changeant son propre état à chaque étape, et exploite le protocole pour produire le prochain
message de la conversation.
Un protocole d’interaction possède quatre caractéristiques [25] : (i) une conversation débute
par un performatif qui exprime l’intention de l’agent qui débute la conversation, (ii) à chaque
étape de la conversation il y a un ensemble fini d’actions possibles, (iii) certains états sont
finaux, et quand ils sont atteint la conversation est terminée, (iv) quand un acte de langage est
réalisé, l’état de la conversation ainsi que les états mentaux des agents sont changés. Un
protocole des plus classiques est le réseau contractuel (Contract Net Protocol) proposé par
Randall et al. [35]. Dans la section suivante, nous faisons une brève présentation de ce
protocole.
Le réseau contractuel (Contract Net Protocol)
Ce protocole offre une solution au problème d’allocation de tâches qui reprend le

fonctionnement du marché. Un agent peut jouer deux rôles par rapport à ce protocole, celui
d’initiateur et celui de participant. Le protocole comporte trois étapes. Dans la première,
l’initiateur réalise un appel d’offre ; c’est-à-dire qu’il annonce à l’ensemble des participants la
tâche qu’il souhaite voir réaliser. Dans la deuxième étape, les participants évaluent leurs
capacités ainsi que leurs intérêts à réaliser cette tâche. S’ils trouvent leur intérêt à réaliser
cette tâche, ils font alors une offre à l’initiateur. Enfin dans la dernière étape, l’initiateur
sélectionne un ou plusieurs participants parmi tous ceux qui ont fait une offre et les informe
de son choix.
Les protocoles d’interaction, définis comme des automates à états, permettent de donner un
cadre à l’interaction entre les agents. Cependant ils limitent l’autonomie des agents en leur
imposant une conduite à suivre.
Notre travail a pour but de définir une approche d’ingénierie des protocoles, supportant des
interactions flexibles des agents pour la satisfaction de besoins d’interopérabilité et
d’intégration énoncés par les organisations, dans les contextes ouverts et décentralisés du
Web. Notre objectif est alors de spécifier, vérifier, exploiter les protocoles d’interaction SMA
et de les adapter pour le contexte d’intégration d’applications par les processus. Pour cela,
dans les sections suivantes, nous allons d’abord donner une brève présentation du langage
semi-formel AUML pour la modélisation des agents. Puis, nous donnons un panorama de
langages formels utilisés pour la formalisation des protocoles d’interaction.
19
5. Langage semi-formel de modélisation ‘’Agent UML’’
Le langage AUML (Agent UML) a été proposé par Bernhard Bauer comme étant une
extension de la notation UML pour la modélisation d’agents [36].
¾ Une représentation des processus simultanés d’interaction permettant ainsi à UML de
modéliser les protocoles d’interactions entre agents. (Par exemple le cas de
transmission de messages à plusieurs destinataires)
¾ La notion de rôle qui permet de modéliser les rôles joués par les agents.
AUML a introduit le diagramme de protocoles qui est une extension du diagramme de
séquences d’UML mais avec des opérateurs logiques, de causalité, de synchronisation et de
diffusion. La présentation sous forme de diagramme de séquences apporte une certaine
intuitivité. La représentation explicite des rôles, et les éléments supplémentaires permettent la
représentation des branches alternatives et du parallélisme.
Aussi, AUML permet l’utilisation des boucles de retour ainsi que la définition de sous-
protocoles.
Un raccourci d’écriture permet de représenter l’arrivée des messages de différentes
alternatives sur une seule et même ligne de vie. La sémantique est alors équivalente à la
réception des messages sur des branches parallèles, séparées en plusieurs lignes de vies.
Dans le diagramme de séquence AUML il existe une spécification plus riche du rôle d'un
agent (un rôle définit le comportement d'un agent dans un système, ex : acheteur, vendeur).
• L'extension du diagramme de séquence donne des étiquettes (acte de communication),
aux flèches au lieu du message style orienté objet.
• L'ajout de nouveaux types de branchements dans les diagrammes de séquence AUML
afin de prendre en compte l'indéterminisme du comportement d'un agent.
La figure 1.8 montre les trois types de branchement proposés par AUML [36]:
• (a) : branchement ET, les actions concurrentes de CA-1 à CA-n.
• (b) : branchement OU, un choix de (0 ou plus) actions envoyées, au plus d’un CA
envoyé, la communication est simultanée (le ou inclusif).
• (c) : branchement XOR, indique le ou exclusif, l’une ou l’autre, mais pas les deux
simultanément.
Figure. 1.8 – Différents types de branchements proposés par AUML [36]
20
La section suivante présente un état de l’art critique des formalismes et des représentations les
plus couramment utilisés à la formalisation des protocoles d’interaction.
6. Aperçu des outils formels
Un grand nombre de travaux de recherche s’intéressent à la vérification et à la validation

formelle des services, des services Web et des Workflows de services. Les réseaux de Petri,
les systèmes états-transitions, les algèbres de processus et les ASM sont considérés comme les
formalismes les plus utilisés.
6.1. Travaux sur l’Abstract State Machines (ASM)
Les ASM (Abstract State Machines) [37] sont des machines à états agissant sur des états
définis par des structures de données. Ce formalisme est également utilisé pour modéliser et
vérifier des processus BPEL. Ainsi, Farahbod et al. [38,39,40] ont utilisé la version
Distributed ASM pour donner une sémantique formelle au langage BPEL à travers la
définition d’un nouveau langage nommé BPELAM (BPEL Abstract Machine). Ce dernier prend
en compte l’aspect dynamique de BPEL (activités simples et structurées) et offre, comme
extension pour les futurs travaux, la possibilité d’ajouter des éléments de gestion des données,
et des gestionnaires d’erreurs et de compensations. BPELAM permet de décrire un processus
BPEL avec la sémantique formelle du formalisme ASM. Le modèle obtenu permet de simuler
et de vérifier des propriétés comportementales dans le service décrit.
Les travaux de Börger et al. [41] s’intéressent à la modélisation des processus et des
Workflows de services en utilisant les ASM. L’approche proposée s’intéresse à la
modélisation du comportement d’un Workflow de services en proposant un modèle générique
d’une transition gardée (WorkflowTransition). Une transition peut appeler une opération (un
service) avec des données de l’état interne du Workflow, une transition peut donner le
contrôle à d’autres événements (transitions), et enfin, elle peut occuper ou libérer des
ressources partagées. Le cas d’implémentation de cette approche avec des processus BPMN
[42] est étudié. La même approche peut être appliquée aux processus BPEL.
6.2. Travaux sur les systèmes états-transitions
Cette section résume les différents travaux, basés sur les systèmes états-transitions, pour la
modélisation et la vérification de la composition des services Web exprimés avec BPEL. Un
système états-transitions est composé d’un ensemble d’états et d’un ensemble de transitions
d’un état à un autre modélisant l’évolution de l’état du système en changeant les valeurs de
l’état.
21
Nakajima [43, 44] est l’un des premiers à modéliser les services Web et les Workflows de
services avec des systèmes états-transitions exprimés dans le langage Promela [45]. Par la
suite, il s’est intéressé particulièrement à la modélisation et à la vérification des propriétés
comportementales d’un processus BPEL. Il a proposé une représentation des activités de
BPEL par les systèmes états-transitions qu’il a codés avec le langage Promela. Ce langage est
utilisé comme entrée du model checker Spin afin de détecter des traces d’exécution où le
système se bloque [46, 47].
Aussi, plusieurs auteurs [48, 49, 50, 51] ont modélisé la chorégraphie (communication) entre
plusieurs processus BPEL par des systèmes états-transitions gardés. Ces systèmes états-
transitions ont été exprimés avec le langage Promela et vérifiés à l’aide du model checker
Spin [52]. Dans la continuité de ces travaux, les types de données exprimés avec XML et
XPath sont modélisés en Promela [48]. Ceci a permis de prendre en compte les déclarations
des données dans la modélisation des processus BPEL et d’exprimer des propriétés en logique
temporelle LTL. Cette approche est surtout utilisée dans le cas de vérification des types de
données énumérées finis afin d’éviter le problème de l’explosion combinatoire du nombre
d’états explorés. L’outil WSAT [53] implémente toute la méthode d’analyse proposée.
En parallèle aux différents travaux utilisant Promela/Spin, [54] ont développé un outil nommé
VERBUS (VERification for BUSiness processes) permettant de prendre en entrée des
langages de description de Workflow comme BPEL ou BPML et de les transformer dans des
formalismes supportés par des outils comme Spin [52] ou SMV [55], afin de vérifier les
propriétés d’absence de blocage ou de détecter les parties du système états-transitions qui ne
sont pas accessibles.
6.3. Travaux sur les réseaux de pétri
Un réseau de Petri [54,55] est un graphe biparti, orienté reliant des places et des transitions
(des nœuds). Deux places ou deux transitions ne peuvent pas être reliées entre elles. Les
places peuvent contenir des jetons, représentant généralement des ressources disponibles.
Comme la sémantique formelle des réseaux de Petri est définie, la majorité des travaux
utilisant ce formalisme, transforme une description d’un processus BPEL en un modèle de
réseau de Petri. Ainsi, le modèle obtenu est analysé à l’aide des techniques et outils définis
autour de cette méthode formelle.
Parmi ces travaux Stahl [56] et Schmidt and Stahl [57] ont défini une transformation d’une
description BPEL en un réseau de Petri. Cette transformation effectue une abstraction des
données et le modèle obtenu permet d’effectuer la vérification des propriétés
comportementales traditionnelles comme l’absence du blocage. Le processus de
transformation est automatisé dans l’outil BPEL2PN (BPEL to Petri Net) [58].
22
Ensuite, les auteurs Verbeek and van der Aalst [59] ont modélisé un processus BPEL à l’aide
d’un type de réseaux de Petri adapté à la modélisation de Workflow nommé Workflow Net.
Le modèle obtenu permet de vérifier des propriétés comme la terminaison du Workflow Net
ou de détecter des nœuds morts grâce à l’outil Wolfan [60]. Les auteurs Ouyang et al. [61] se
sont intéressés à la partie dynamique de BPEL en modélisant, à l’aide des réseaux de Petri, les
différentes activités structurées de BPEL. Le processus de transformation est automatisé dans
l’outil BPEL2PNML (BPEL to Petri Net Makup Language). Le modèle obtenu est utilisé
comme entrée de l’outil WofBPEL [61] afin de détecter les activités qui ne sont jamais
exécutées, les activités qui se mettent en attente du même message, ainsi que d’autres
propriétés liées à la bonne exécution des activités de BPEL. Une synthèse permettant d’avoir
une approche de modélisation et d’analyse des services Web et de Workflow, basée sur les
réseaux de Petri, est réalisée par van der Aalst et al. [59].
Lohmann s’est également intéressé à la modélisation des processus BPEL en utilisant les
réseaux de Petri.
D’autres travaux, utilisant les réseaux de Petri pour la modélisation de la composition des
services Web décrits avec BPEL, existent. Nous citons, entre autres, les travaux de Martens et
al. [61] basés sur l’analyse de la compatibilité de comportement pour la vérification des
propriétés comportementales d’un processus BPEL. Les réseaux de Petri colorés sont
également utilisées dans certains travaux de recherche. Nous citons les travaux de Yi and
Kochut [62], qui ont utilisé ce type de formalisme pour vérifier le comportement d’un
processus BPEL, et les travaux de Yang et al. [63] qui ont également utilisé les réseaux de
Petri colorés pour vérifier l’orchestration du point de vue local et la chorégraphie du point de
vue globale dans un Workflow de services Web.
6.4. Travaux sur l’algèbre des processus
Les algèbres de processus sont des langages formels permettant de modéliser les systèmes
concurrents et/ou distribués. Elles sont largement utilisées dans le domaine des services Web
et des architectures orientées services [64, 65]. Dans cette section, nous reprenons une partie
des travaux de recherche, basés sur les algèbres de processus, réalisés dans le cadre de la
modélisation et de la vérification des Workflows de services et de la composition de services
Web décrite avec BPEL.
Cependant, Magee et Kramer [66] ont développé une algèbre de processus nommé FSP
(Finite State Process) permettant de représenter un système états-transitions finis étiquetés par
un outil nommé LTSA (Labelled Transition System Analyser).
Dans ses travaux de recherche, Foster [67] s’est appuyé sur l’algèbre du FSP pour modéliser
des processus BPEL. Dans Foster et al la spécification du service est exprimée en UML [68]
sous la forme de Message Sequence Charts (MSCs) et l’implémentation du service est décrite
23
en BPEL. Les deux formalismes sont traduits vers FSP et les traces produites par les deux
modèles sont comparées pour vérifier si le comportement de l’implémentation respecte la
spécification du MSC. Un outil, nommé LTSA-WS [69], permet de traduire les activités de
BPEL et les MCS vers FSP et d’implémenter l’approche proposée par Foster sur des
processus BPEL. Le même principe est utilisé dans [69] pour vérifier la compatibilité de la
communication entre plusieurs processus BPEL dans un protocole décrit par une
chorégraphie.
Salaün et al. [69] ont proposé une approche générique pour la modélisation et la vérification
de la composition des services Web. Cette approche permet de définir un lien (règles de
transformation) entre les modèles abstraits représentés par les différents formalismes des
algèbres de processus, et les langages d’implémentation des Workflows de services Web
comme BPEL ou CDL. Un exemple traitant le cas de l’application de cette approche sur une
algèbre CCS [74] et le langage BPEL est traité dans l’article [70]. Le modèle obtenu est utilisé
pour vérifier des propriétés de sécurité et des propriétés de vivacité exprimées en logique
CTL. Ces travaux sont étendus en utilisant l’algèbre LOTOS [71] afin de prendre en compte
la description des données [71]. Dans le même contexte, Ferrara [72] a proposé une approche
basée sur LOTOS pour la vérification des processus BPEL abstraits. Cette approche permet,
du point de vue méthodologique, de faire des transformations dans les deux sens, et du point
de vue de la vérification, de vérifier des propriétés de vivacité, de sûreté, de bi-simulation, de
simulation et d’exécuter des scénarios.
Seul ce type de formalisme à savoir le pi-calcul est introduit, car il intervient dans la suite du
manuscrit.
6.4.1. Utilisation du pi-calcul
De nombreux langages, présentes comme des algèbres de processus, ont été développées pour
une compréhension formelle et la spécification d'applications SOA. Dans notre travail, nous
nous sommes basées sur le pi-calcul. La conception de nombreux langages d'orchestration tels
que XLANG Thatte, Microsoft BizTalk Server 3 et WS-BPEL, sont fortement inspirés de la
métaphore de communication inspirée du pi-calcul Milner et al. [74] basée sur l'échange de
messages dans un contexte distribué.
Le pi-calcul est un langage formel, développé pour raisonner sur les systèmes distribués
communicants et spécifier le comportement de processus concurrents, c.à.d. des systèmes
dont le nombre de processus ainsi que les liens de communication entre processus peuvent
varier dynamiquement.
C'est un modèle algébrique fondé sur la notion d'interaction et le mécanisme de nommage. Ce
calcul est souvent utilisé pour établir des preuves d'équivalence entre des modèles de
systèmes distribués. Ce langage est adéquat pour l'analyse formelle des langages
24
d'orchestration, eux mêmes basés sur les échanges de messages. De plus sa prise en charge de
la mobilité peut s'avérer utile dans de nombreuses situations. La caractéristique principale du
langage est la possibilité de transmission d'un lien de communication (nom) entre deux
processus; le destinataire peut alors utiliser ce nom pour une nouvelle interaction avec d'autres
parties.
6.4.2. Définitions
Soit N un ensemble infini de noms, que nous noterons la syntaxe des processus (ou
termes) notés P; Q; R est donnée par la grammaire suivante :

Les actions préfixes
sont définies par la grammaire :
Les actions que les agents peuvent exécuter sont définies par :
Où x et y sont des noms libres. Intuitivement, x<y> envoie le nom message y sur le canal x,
x(y)P reçoit un nom sur le canal x puis exécute le processus P où y représente le nom reçu,
P1|P2 est l'exécution des deux processus en parallèle, et (vx)P restreint la portée de x au
processus P (une autre interprétation est que le nom x est fraîchement créé dans P).
est l'action silencieuse. L'opérateur d'égalité (matching) [x = y]P permet de tester l'égalité
syntaxique des noms, i.e si x et y sont identiques alors P est exécuté. La somme (+) et la
composition parallèle ( | ) expriment le non-déterminisme et la concurrence.
P; Q;:= … A(y1,.., yn) est une définition paramétrique récursive qui permet de préciser un
comportement infini (boucle). A(y1,..,yn) est un identificateur (ou appel, ou invocation)
d'aritè n. Nous supposons que chaque identificateur a une définition unique, qui peut être
récursive A(x1;…; xn) = P où les xi sont distincts deux à deux. L'intuition est que A(y1;… ;
yn) se comporte comme son P où chaque yi remplace xi.
Il existe une autre manière de spécifier des comportements infinis basée sur la réplication en
utilisant l'opérateur (!). Nous n'aborderons pas cette technique, car cet opérateur n'a pas son
équivalent dans WS-BPEL qui supporte par contre les définitions récursives.
Les occurrences de y dans x(y).P et (vx).P sont liés. Les noms libres sont définis comme étant
des noms pouvant prendre n'importe quelle valeur. Nous notons que fn(P) est l'ensemble des
noms libres de l'agent P; tandis que bn(P) représente l'ensemble des noms liés dans P et nous
avons n(P) = fn(P) U bn(P).
25
6.5. Logique temporelle pi-logique
La pi-logique permet de spécifier le comportement d’un systéme écrit en pi-calcul de maniére

formelle et non ambigüe. Cette logique a été introduite dans Ferrari [73] pour exprimer les
propriétés temporelles.
Définition :
La -logique reprend les modalités définies par Milner [70] en y ajoutant les modalités EF
et F{ } relatives au futur possible.
La syntaxe se présente comme suit :
Où est une action du pi-calcul et pouvant être est un est un

ensemble fini.
La sémantique des pi-formules est données par les régles suivantes :
-
-
-
-
-
-
La signification de est que la vérité de doit être précédée de l’occurrence d’une

séquence d’actions .
Comme d’habitude, des opérations duaux sont aussi définis :
-
-
-
-
-
Les formules de la pi-logique sont suffisamment expressives pour permettre d'exprimer et de
26
vérifier naturellement les propriétés de vivacité (liveness) et bien d'autres propriétés encore.
6.6. Synthèse
A l’image de cette étude, nous relevons l’importance des différents outils formels qui existent.
En plus des critiques apportées séparément à chacun des formalismes décrits ci-dessus, nous
pouvons dire que l'intérêt des l'ASM se trouve sur leurs expressivités et leurs simplicités.
Ils permettent de concevoir des spécifications réalisables et qui peuvent être vérifiées
directement sur le modèle. Cependant, cette technique n'est pas adaptée à des applications qui
traitent des données de lot et c'est le cas du service Web qui peut échanger des volumes très
importants d'information. Nous avons vu que les réseaux de petri permettent de modéliser des
événements et des états dans un système distribué. Ils permettent d'exprimer simplement
séquentialité, concurence et contrôle asynchrone basé sur des événements. Ils présentent des
avantages pour la modélisation de workflow par exemple en offrant une sémantique formelle,
bien que graphique. D'autres avantages et que leur sémantique est basée sur les états et non
seulement sur les événements. Il existe beaucoup d'outils pour l'analyse. Cependant, les
réseaux de Petri ne sont pas exempts de problèmes [17]. Ainsi, certaines difficultés
apparaissent avec l'utilisation comme la difficulté à représenter plusieurs instances d'un sous-
processus ou de représenter des motifs de synchronisation complexes (motif d'annulation
(propre)).
Cependant, les Algèbres de processus sont utilisées dans différents domaines, grâce à leur
grande capacité de modélisation et de leur relative simplicité de l'écriture. Ils permettent de
décrire l'évolution et le comportement des interactions réalisables dans des systèmes
concurrents. Ils sont souvent représentés par des langages de programmation réduits à une
simple expression [18]. Ils sont adaptés pour décrire les services Web, car ils offrent une
description formelle des processus dynamiques, ce qui facilite leur vérification automatique.
Ils permettent une grande expressivité et fournissent des constructions qui sont adaptées à la
composition parce qu'ils ont des propriétés de composition. Enfin leur notation textuelle est
adaptée à la description de réels problèmes de taille, même si elle est moins lisible que les
systèmes de transitions. Pour cela, nous allons adopter le π-calcul pour atteindre nos objectifs.
7. Quelques travaux reliés aux PI
Plusieurs travaux ont proposé des modèles pour représenter les SMA. Nous mettons en
exergue quelques uns qui nous semblent intéressants et qui ont une relation avec notre travail.
Selon Kishore et al. [74] les seuls acteurs sont des agents intelligents, et les acteurs humains
sont généralement considérés comme des utilisateurs du système. Certains auteurs ont utilisé
des langages de modélisation issus du génie logiciel, notamment UML.
27
D’autres travaux ont abordé la problématique de la modélisation des communications entre

organisations, en utilisant notamment le concept de contrat [4], [5]. D’autres encore ont
proposé une vision d’un processus métier comme une succession de cycles de communication
entre les différents participants [75]. Kishore et al. [74], proposent un cadre unificateur entre
la modélisation des SMA et celle des systèmes de coordination, permettant de spécifier les
interactions entre processus métiers.
Selon El Fallah-Seghrouchni et Haddad [76] le plan global est supposé non nécessaire puisque
l’approche considérée est basée sur le paradigme de planification orientée agent. En fait, cette
supposition ne convient pas aux applications de BPI (Business Process Integration) où la
planification d’un comportement global est nécessaire.
Marc et al [77] montrent qu’il est possible de modéliser les plans des agents en termes
d’automates hybrides. Le SMA associe à chaque tâche réalisée un graphe de dépendances qui
représente la décomposition d’une tâche en sous tâches. Les principaux avantages de ce
formalisme sont le contrôle et la validation des plans individuels et multi-agents.
Un inconvénient de l’approche de Buhler et al. [78] est que le passage des différents modèles
vers le modèle agent nécessite un grand effort. Par ailleurs, aucune étape de validation afin
d’assurer l’exactitude des interactions entre les agents n’est prévue. D’autres travaux reliés à
la communication entre agents et la modélisation des systèmes ont procédé du point de vue
des protocoles d’interaction. Comme l’utilisation d’un langage naturel est illimitée, la théorie
des actes de langage [79] exprime qu’il est possible de grouper les termes en un nombre fini
de groupes d’actions verbales baptisés "les actes de langage".
Cette théorie introduit la notion de protocole de communication pour représenter les différents
comportements des agents sociaux. Comme il a été détaillé dans [31], la théorie des actes de
langage est utilisée dans plusieurs applications dans les domaines des systèmes répartis, des
protocoles d’échange de données électroniques, etc. L’approche utilisée dans l’IAD exploite
cette théorie pour formaliser les protocoles de communication entre les agents. Singh propose
dans [80] une classification en sept catégories d’actes : assertions, expressions, déclarations,
promissions, permissions, directions et prohibitions.
En effet, Chang et al [81] utilisent la théorie des actes de langage qui exploite l’information
basée sur l’ordre partiel laquelle n’est pas suffisante pour construire un protocole complet de
négociation. Ceci est dû au fait que l’ordre partiel ne fournit pas l’information de type
branchement ou de type raisonnement concernant un argument défié.
Cependant, Desai et al. [82] qui utilise une ontologie permet aussi la composition de
protocoles. L’inconvénient de cette proposition est la faiblesse du pouvoir exprimer les
protocoles en terme de structures de contrôle car elle ne permet pas de spécifier des protocoles
complexes (notamment concurrents et itératifs) mais offre seulement la possibilité de définir
des échanges de messages assez simples. En plus, les auteurs n’envisagent aucune étape de
validation afin d’assurer l’exactitude des protocoles.
28
Synthèse
A l’image de cette étude, nous relevons l’importance de l’approche agent et plus précisément,
les protocoles d’interaction multi-agents pour modéliser les interactions entre processus
métiers.
En plus des critiques apportées séparément à chacune des approches décrites ci-dessus, nous
avons pu constater l’absence d’une démarche complète pour l’ingénierie des protocoles
d’interaction dans le cadre d’intégration d’applications.
La plupart des travaux mentionnés dans la section précédente, se concentrent sur une étape
précise. Par exemple, le cadre conceptuel proposé par Kishore et al. [73] traite la modélisation
des processus métiers à l’aide des SMA. Dans ce cas, les auteurs ne prévoient aucune étape de
validation afin d’assurer l’exactitude des modèles développés.
Les travaux de El Fallah-Seghrouchni et Haddad [76] traitent seulement les étapes de
modélisation et de vérification. L’exploitation (au moment de l’exécution) des modèles
d’agents développés est complètement ignorée.
Nous définissons dans notre thèse un guide permettant de passer à partir de descriptions semi-
formelles des PI, vers des spécifications formelles en pi-calcul tout en mettant l’accent sur le
contrôle et la dynamicité des interactions. Sachant que le langage pi-calcul permet de couvrir
les aspects de modélisation et de validation des protocoles.
8. Conclusion
Dans ce chapitre nous avons fait un survol sur les concepts liés aux e-services. En effet, nous
avons présenté les Services Web ainsi que les technologies qui leurs sont afférentes et puis
nous avons présenté les systèmes multi-agent.
Nous avons porté une attention particulière au langage WS-BPEL que nous avons exposé,
étant donné que nous nous intéressons à sa vérification formelle.
Par la suite, nous avons présenté un état de l’art sur les concepts d’agent, SMA, d’interaction,
de protocole d’interaction. Puis, nous avons abordé le formalisme semi-formel Agent UML
qui permet d’exprimer clairement les processus de communication entre agents qui impliquent
des structures conditionnelles assez lourdes à représenter avec UML.
Nous avons dégagé tout au long de ce chapitre un ensemble de principes et de besoins
essentiels pour la conception de SMA.
Dans la seconde partie de ce chapitre, nous avons présenté un panorama des modèles et des
langages pour la formalisation des protocoles d’interaction. La formalisation, qui permet de
vérifier des propriétés souhaitables d'un système sans se soucier des détails de son
implémentation, qui peut être réalisée grâce à de nombreux formalismes. Parmi ceux-ci, le pi-
calcul qui s'avère très adapté pour cette tâche.
29
Pour terminer, nous avons présenté la logique temporelle pi-logique pour exprimer l’ensemble
des propriétés que nous souhaiterons vérifier dans l’approche que nous proposerons dans le
chapitre 3.
30
2
Intégration et interopérabilité
des services en ligne
1. Introduction
Dans le chapitre précédent, nous avons présenté les différents concepts et outils liés aux e-
services à savoir les SOA et les différents formalismes pour la modélisation et la vérification
de la composition des services web.
Cependant, les processus métiers ont pris une place prépondérante dans les systèmes
d’information durant ces dernières années grâce à leurs bénéfices remarquables. Face à la
concurrence et dans le but d’améliorer leur productivité, les systèmes d’information
expriment un grand besoin d’ouverture et de coopération à l’échelle mondiale. Elles ont
besoin de s’allier à d’autres systèmes de compétences complémentaires afin de coopérer avec,
et de réaliser des projets qui ne sont pas à la portée d’un seul système, par exemple,
externalisations intensives de processus et de services métiers.
Cependant, pour coopérer, les systèmes doivent adopter de nouveaux schémas de
comportement, modifier éventuellement leur organisation et à s’ouvrir davantage à leur
environnement et s’organiser en réseaux, au sein desquels interagissent différents acteurs
(fournisseurs, sous-traitants, etc.) afin de pouvoir répondre rapidement aux exigences et aux
évolutions du marché.
Pour faire face à ces nouvelles exigences, les systèmes d’information ont souvent recours au
concept d’intégration et parfois, de façon plus spécifique, au concept d’interopérabilité.
Dans les e-services l’interopérabilité est désormais incontournable si elles souhaitent
s’inscrire dans une dynamique d’intégration et assurer la pérennité économique. Dans ce qui
suit, nous allons définir le concept d'intégration et celui de l'interopérabilité en mettant en
évidence la différence qui existe entre ces deux concepts et les outils relatifs à chacun deux.
31
Intégration et interopérabilité des services en ligne
2. Intégration vs interopérabilité
Les problèmes d'intégration et d'interopérabilité ne sont pas nouveaux et ils constituent des
domaines de recherche auxquels s'intéressent plusieurs communautés dont celle des systèmes
d'information, celle des bases de données, celle du génie logiciel, celle des systèmes
Workflows, etc. Plusieurs approches, standards et/ou technologies ont été proposés pour
résoudre ces problèmes.
2.1. Concept d’intégration
Plusieurs définitions ont été avancées dans la littérature. Selon le dictionnaire, l'intégration
désigne l’action d’intégrer qui signifie "rendre entier", faire entrer dans un ensemble. Pour
Vernadat [83], l'intégration d'entreprise définit comme étant le processus qui "consiste à faire
interopérer fortement les personnes, les machines et les applications afin d'accroître la
synergie au sein de l'entreprise". Selon Weston [84] l'intégration de façon générale, consiste à
combiner des composants de telle façon à former un nouvel ensemble constituant un tout pour
créer de la synergie.
Pour certains auteurs [85], l'intégration d'entreprise est définie comme étant "la coordination
de tous les éléments incluant les processus métiers, les ressources humaines et la technologie
d'une entreprise, qui fonctionnent ensemble dans le but d'atteindre la réalisation optimale de la
mission de cette entreprise telle que définie dans la stratégie de l'entreprise".
Par contre Boudjlida [86] définit le concept d’intégration comme étant "la capacité de
communication (par partage de données, par envoi de messages ou d’évènements) entre des
outils ou des applications éventuellement hétérogènes et distribuées. Lorsque celle-ci est
augmentée de la capacité de coopération, on parlera, dans ce cas, d’une interopérabilité.
2.2. Concept d’interopérabilité
Plusieurs définitions ont été proposées dans la littérature pour définir le terme
"interopérabilité". Nous n’en citons que quelques unes :
9 L’interopérabilité est la capacité des systèmes informatiques et des processus de
supporter l’échange de données et de permettre le partage d’information et de
connaissances [87] ;
9 L’interopérabilité est la capacité que possèdent deux ou plusieurs systèmes ou
composants à échanger des informations puis à exploiter les informations venant d’être
échangées [88];
9 L’interopérabilité est la capacité de communiquer avec d’autres systèmes et d’accéder
à leurs fonctionnalités [83];
32
9 Pour Carney et al [89], l’interopérabilité est définie comme étant : "l’interopérabilité

est la capacité d’une collection d’entité communicantes pour (a) partager des
informations spécifiques et (b) traiter ces informations selon une sémantique
opérationnelle convenue" ;
9 Dans le domaine du Workflow, la WfMC (Workflow Management Coalition) a défini
l’interopérabilité des modèles de Workflow comme étant la possibilité qu’ont plusieurs
moteurs Workflow de communiquer pour exécuter de manière coordonnée des
instances de procédures sur l’ensemble de ces différents moteurs [90].
Dans notre contexte, le concept d’interopérabilité entre participants définit la notion d'échange
de messages et de coopération entre les agents malgré les différences dans les langages de
spécification et les environnements d'exécution. Par définition, la coopération signifie qu’un
ensemble de partenaires ont la volonté de réunir leurs compétences et de travailler ensemble
pour atteindre un objectif commun dans un contexte organisationnel.
Dans le cadre de nos travaux, nous considérons que l’intégration comme un concept
générique incluant le concept d’interopérabilité (en se basant sur le principe de Vernadat [83])
tout en nous focalisons sur le concept d’intégration. Dans les sections suivantes, nous
expliquerons plus en détail ces deux concepts.
3. Principaux types d’interopérabilité

Plusieurs équipes de chercheurs se sont penchées sur la définition de cadres caractérisant les
différents aspects de l’interopérabilité. Parmi lesquels, nous citons IDEAS (Interoperability
Development for Enterprise Applications and Soft- ware) [91], AIF (Application Integration
Framework) [92] et EIF (European Interoperability Framework ) [93]. L’IDEAS est défini par
quatre aspects : sémantique, technologies de communication, connaissances, et métier. Le
cadre AIF est défini par trois aspects : technique, applicatif, et conceptuel. Enfin, EIF est
défini par trois aspects: technique, sémantique, et organisationnel. Ces trois cadres convergent
tous vers les aspects considérés dans l’EIF à partir duquel il est possible de considérer les
aspects d’interopérabilité des SI des entreprises : technique, sémantique et organisationnel
[94]. Ces aspects, souvent nommés comme niveaux, sont décrits dans la suite de cette section.
3.1. Interopérabilité technique
L’interopérabilité technique signifie que les messages peuvent être transportés d’une
application à une autre [95]. L’interopérabilité technique n’est pas restreinte aux applications,
mais elle établit plutôt certaines liaisons possibles entre le niveau technique de
l’interopérabilité des entreprises et les dimensions qui caractérisent les SI (données,
applications et processus) [94]. Concernant l’interopérabilité technique des données, elle
concerne les interfaces et les protocoles de communication nécessaires à l’échange des
33
données entre systèmes d’information. Le standard XML représente une solution permettant
la structuration des informations qui peuvent être échangées entre SI.
Concernant l’interopérabilité technique des applications, elle concerne les applications qui
s’exécutent sous des systèmes d’exploitation différents (UNIX, Windows, etc.) ou qui sont
développées dans des environnements incompatibles (.NET, JAVA, etc.). Les services Web
présentés dans le chapitre 1 section 2 et l’EAI sont deux technologies différentes qui se basent
sur le standard XML. En ce qui concerne l’interopérabilité technique des processus, elle traite
l’exécution d’un processus collaboratif faisant intervenir les applications, les données et les
processus internes des SI.
Dans la suite de cette section, nous présentons les exemples de technologies que nous venons
de citer.
3.1.1. XML
Le standard XML (pour eXtended Markup Language) [5] est un langage permettant la
structuration des données qui prend aujourd’hui une place prépondérante dans le domaine des
SI. XML permet la représentation des données et des documents structurés sans l’utilisation
de balises prédéfinies. Par conséquent, il peut être étendu de façon à y ajouter des balises
spécialisées afin de décrire au mieux chaque type de données. Cette flexibilité est
particulièrement recherchée dans toute problématique d’interopérabilité. Aussi, XML décrit
un ensemble de règles syntaxiques, de façon à placer de manière cohérente et correcte les
balises à l’intérieur d’un document XML. Un tel document respectant toutes ces règles
imposées est dit bien formé. L’avantage de toutes ces règles est de permettre la création de
parseurs XML qui seront utilisés afin de lire et d’extraire les données d’un document XML.
3.1.2. EAI
L’EAI (pour Entreprise Application Integration) est un ensemble d’outils et de progiciels

d’intégration offrant un moyen de connecter et de faire communiquer entre elles les
applications de l’entreprise, existantes ou à venir [96]. Il existe une forte relation liant l’EAI et
les processus des entreprises et le Système de Gestion de Workflow [94].
La figure 2.1 montre que l’exécution des activités des processus est basée sur différentes
applications hétérogènes de l’entreprise. L’EAI fonctionne en les faisant interagir, suivant un
processus défini, afin de proposer une vision unifiée de l’information.
34
La technologie EAI se base sur une architecture permettant à chaque application de se

connecter au SI de façon indépendante et unique, sans avoir connaissance a priori du domaine
global. L’application obéit aux ordres du SI en traitant des tâches et en retournant des
Figure.2.1 – Intégration par les processus métiers des applications de l’entreprise [94]
informations suivant l’exécution des processus métiers [94].

Le principal reproche que l’on peut faire aux outils d’EAI consiste en leur aspect propriétaire
[94]. La logique d’intégration d’un EAI étant propriétaire, les éléments de l’outil
(connecteurs, transformateurs de données, orchestrateur des processus) ne sont pas
standardisés, ce qui lie l’entreprise à l’éditeur qu’elle aura choisi, avec les conséquences
coûteuses (coût du conseil et des interventions, pérennité de la solution, etc.) [94].
D’après [97], il est possible de positionner les travaux de l’intégration dans deux catégories du
EAI : l’intégration d’applications dans une compagnie (intra-EAI) [98], et l’intégration B2B
(e-business ou inter-EAI) [99].
Malgré son importance, l’EAI n’arrive pas à apporter la flexibilité demandée dans les
environnements modernes de collaboration où la notion de faible couplage entre les SI des
entreprises en collaboration est très recherchée. Néanmoins, cette notion est présente dans
paradigme SOC [22] dans lequel elle représente son critère clé.
3.2. Interopérabilité sémantique
L’interopérabilité sémantique assure que l’information échangée (concernant les données, les
applications ou les processus) a le même sens du point de vue de son expéditeur et du point de
vue de son destinataire [100]. L’interopérabilité sémantique garantie que le sens exacte des
informations échangées peut être compris par toute application qui n’a pas été conçue
initialement dans ce but. Elle vise à garantir la cohérence dans la manière dont les
informations sont représentées et compromises [101].
Afin de mieux éclaircir la notion d’interopérabilité sémantique, prenons le cas qui étudie les
trois systèmes suivants. Dans le premier système, un citoyen est décrit comme un «
35
contribuable », dans le deuxième système il est décrit comme un « patient », et dans le

troisième il est décrit comme un « étudiant ». Ce cas décrit un conflit sémantique de type
synonymie (plusieurs noms recouvrent un même concept) et sa résolution doit faire appel à un
rapprochement des différentes interprétations sémantiques des éléments du SI. Cependant,
avant d’établir ce rapprochement sémantique, les entreprises doivent d’abord bien définir,
décrire et formaliser les connaissances liées à leurs SI, afin de pouvoir les partager avec
d’autres. Dans ce contexte, les ontologies représentent le candidat idéal pour la
conceptualisation des connaissances des SI.
3.2.1. Ontologie
Le terme ontologie avait au début de son acceptation un sens philosophique. Aujourd’hui, il

est appliqué dans différents domaines tels que la représentation de l’information et des
connaissances, l’intégration des SI, la spécification des systèmes, et l’interopérabilité. Une
ontologie est souvent représentée en termes de classes, relations, propriétés, attributs et
valeurs. L’ontologie dans le contexte d’une entreprise est une composante de la mémoire
d’entreprise qui permet de capturer une connaissance potentiellement intéressante pour cette
entreprise [100]. L’ontologie dans le contexte de l’interopérabilité des entreprises est un pont
entre différents systèmes qui sert à définir le format d’échange entre ces systèmes [102].
3.2.2. Quelques projets sur l’interopérabilité sémantique
Dans le domaine du e-Government qui sera présenté dans la section 9 de ce même chapitre,
nous citons le projet OntoGov visant à développer, tester et valider une plateforme enrichie
sémantiquement permettant de faciliter la composition, la reconfiguration et l’évolution des
services de l’e-governement [103]. Un autre projet, aussi intéressant, est le projet ISyCri
décrit dans [104]. Ce projet utilise une ontologie de crise pour fournir aux partenaires
impliqués dans la gestion d’une crise avec une médiation de SI agiles. Cette médiation
supporte en plus de l’interopérabilité des SI, la coordination de leurs activités à travers un
processus collaboratif.
3.3. Interopérabilité organisationnelle
L’interopérabilité organisationnelle des entreprises est un ensemble de responsabilités,

autorisations, confiances, aspects légaux, propriétés intellectuelles et structures
organisationnelles nécessaires à l’acceptation des échanges d’informations [94]. Cette
définition est inappropriée au domaine des SI [94]. Il est possible de la filtrer et n’en garder
que ce qui touche directement aux SI en imaginant deux classes d’informations : la première
36
classe concerne les stratégies et les décisions relatives aux entreprises et une deuxième classe
qui contient les autres informations, portant sur les processus, données et applications de
l’entreprise [94]. L’interopérabilité des SI se réfère alors à tout ce qui a trait à la seconde
classe en y associant l’aide à la décision.
L’interopérabilité organisationnelle référencie la notion de processus collaboratif permettant
d’expliquer la synchronisation des échanges d’information et de ressources entre partenaires
[94]. Cette notion est particulièrement importante dans un contexte d’entreprises en réseau.
L’interopérabilité organisationnelle a été abordée dans [94] mais sous le nom de
l’interopérabilité pragmatique qui vise à capturer la volonté des entreprises à collaborer
ensemble.
3.4. Discussion
Différents niveaux d’interopérabilité ont été évoqués dans divers travaux. Nous nous
limiterons à l’essentiel, i.e., les plus figurants. Selon notre étude qui a été effectuée, presque
chaque auteur détermine plusieurs niveaux d’interopérabilité. En général ces niveaux sont de
haut ou bas niveau.
Pour Salzano [105], deux niveaux d'interopérabilité émergent d'une part, le niveau technique
concerne la communication et l'échange de données; d'autre part, le niveau sémantique est lié
à l'utilisation partagée de la connaissance, et les informations échangées à partir des systèmes
disparates.
Selon Diego et al. [106], les systèmes d'information sont obligés de soutenir la
communication et la coopération (interopérabilité) à différents niveaux: interopérabilité
technique, niveau signal et protocole, interopérabilité structurelle réalisée par l'échange de
données simples, interopérabilité syntaxique par l'échange des données significatives avec un
vocabulaire accepté, interopérabilité sémantique avec des modèles d'information commun,
interopérabilité organisationnelle/service basée sur des modèles d'affaires et des services
communs enchaînés.
Touzi [94] décrit trois niveaux d’interopérabilité de données pour les SI dans un contexte
général : interopérabilité métier des données, interopérabilité sémantique des données et
l’interopérabilité technique des données.
Ces différents niveaux de l’interopérabilité sont confrontés à trois types de barrières : des
barrières d’ordre conceptuel provenant de la diversité des modes de présentation et de
communication des concepts; d’autres d’ordre technologique provenant de l’utilisation de
technologies différentes pour communiquer et échanger des informations ; et finalement ceux
d’ordre organisationnel provenant des différents modes de travail par exemple.
Nous en déduisons que les SI doivent donc bien décrire et définir leurs systèmes afin de
pouvoir partager leurs informations avec d’autres organisations. En effet, nous devons nous
assurer que les informations échangées entre eux sont compréhensibles du point de vue de
37
leur signification et de leur interprétation. L’interopérabilité technique est capitale pour

l’interopérabilité des entreprises. Ce niveau concerne la capacité à mettre en communication
les SI. L’interopérabilité technique permet de faciliter la mise en œuvre des autres niveaux
d’interopérabilités : organisationnel et sémantique.
Dans le contexte de notre travail, nous nous intéressons au niveau organisationnel. Nous
voulons dire par organisationnel les rôles, les activités et même les responsabilités.
L'analyse des différentes techniques d'interopérabilité vis-à-vis de notre problématique et des
objectifs visés, nous a permis de recenser les points essentiels suivants :
• Les techniques basées sur des outils EAI permettent d'intégrer l'ensemble des
fonctionnalités de l'entreprise au niveau d'une application monolithique. Leur
principale limite est leur lourdeur et leur caractère propriétaire. Leur utilisation est
beaucoup plus technique, ce qui limite considérablement la flexibilité.
• Les techniques basées sur le modèle architectural SOA contribuent à l’évolutivité, à la
flexibilité et la pérennité d'un système d'information et fournit une réponse
conceptuelle adaptée à la problématique de l’interopérabilité. Cependant, sa principale
limite est que, c'est un modèle point à point qu'on doit se conformer selon la vision
SOA (consommateur et fournisseur de services).
4. Différents aspects de l’interopérabilité

La présence d’hétérogénéités entre les SI coopératifs distribués et ouverts est inévitable.
Cependant, Zhang et al. [107] déterminent plusieurs problèmes et difficultés pour
l’interopérabilité dans les SI :
a/ Interopérabilité des systèmes de base de données: les données sont souvent situées dans
des différents systèmes de bases de données. Cependant, les données provenant des systèmes
de base de données différents (par exemple Microsoft SQL Server, Oracle, Microsoft Access,
etc.) ne peuvent être échangés entre eux et utilisés par des applications basées sur SGBD
différents. Pour surmonter ce problème, quelques systèmes d’information optent pour une
base de données unique au sein de leurs organisations. Par conséquent, cette fonctionnalité
fait perdre à des SI la flexibilité de la transmission de données avec d'autres systèmes.
b/Interopérabilité des langages: généralement, différents systèmes pourraient être
développées par différents fournisseurs de logiciels, comme les dossiers médicaux. Les
développeurs utilisent des langages de programmation différents pour construire leur SI (par
exemple Java, C + +, C #, etc.). Cela risque de rendre la réutilisation et le partage
d'applications très difficile à cause de l'incompatibilité entre les différents langages de
programmation.
c/ Interopérabilité des plates-formes systèmes: les différents systèmes pourraient être
développés sur des plates-formes de développement différents (par exemple les systèmes
d'exploitation Microsoft Windows, Linux Systems, les navigateurs web, au cours des
38
dernières années, le navigateur Internet est devenu une plate-forme en elle-même, etc.), cette
fonctionnalité rendrait ces systèmes opérant que sur certaines plates-formes systèmes. Par
exemple, si un SI est construit sur la base des plates-formes Windows système qui sont eux
même limités de fonctionner sur d'autres plates-formes (par exemple Linux).
d/ L’interopérabilité des données : l'interopérabilité au niveau des données exige une
participation dans l'élaboration de normes et standards pour la description des données
(données de référence), d'accès aux données (interfaces de base de données), et transport de
données (représentation et protocoles). Les données utilisées doivent être à jour [38]. En effet,
les partenaires ont besoin d’échanger ces données syntaxiquement et sémantiquement
interopérables. Il faut donc disposer de formats et/ou d’une ontologie en commun pour
pouvoir appréhender ces informations aux plans syntaxiques et sémantiques. Selon le type de
processus et de 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 faiblement couplée. Ce couplage
faible (interconnexion via le partage d’information) donne une grande souplesse du SI global
[39].
e/ Interopérabilité des services : Il s’agit d’identifier, composer et rassembler des fonctions de
différentes applications conçues et implémentées séparément. Ceci passe par la résolution des
différences syntactique et sémantique aussi bien que la connexion aux différentes sources
d’information. Le terme « service » n’est pas limité à la notion de « web service » ou une
application particulière, mais s’étend pour couvrir les fonctions d’une compagnie ainsi que les
entreprises en réseaux.
f/ Interopérabilité des processus : Un processus est définit par une séquence de services
(fonctions) pour répondre à un besoin spécifique de l’entreprise. Généralement, ces processus
évoluent en interaction (en série ou en parallèle). Il faut étudier comment connecter des
processus internes et créer de nouveaux processus en commun. L’interopérabilité inclut des
mécanismes pour lier les langages de description des processus (les standards de workflow),
des processus distribués et décentralisés ainsi que leur formation et vérification. Ce type de
problème sera abordé dans cette thèse en proposant un mécanisme bien clair. Cependant,
diverses organisations faisant différents processus métier et ayant différents systèmes, ce qui
rend plus complexe pour interagir avec d’autres différents systèmes.
L’objectif de la section suivante est de mettre en exergue les différents travaux liés au concept
d’interopérabilité.
39
5. Quelques travaux liés à l’interopérabilité et aux services
Dans cette section, nous étudions quelques travaux de recherches qui ont abordé les deux
concepts : interopérabilité et service.
5.1. Travaux antérieurs
D’après Baldoni [108], l’interopérabilité représente la capacité de produire une interaction.

Cette interopérabilité est garantie par le respect de certaines règles définissant le
comportement global du système incluant les parties (services) qui sont en coopération. Ces
règles sont connues sous le nom de protocoles d’interaction dans le domaine des systèmes
multi-agent présentés dans le chapitre 1 section 4. D’après [109] et [110], l’interopérabilité est
une propriété désirée dans un système composé d’entités interagissant, et que sa vérification
est fondamentale puisqu’elle permet de vérifier le bon fonctionnement du système.
La vérification proposée par Baldoni et son équipe est connue dans d’autres approches sous le
nom anglais «conformance test». Alors que ces approches ont échoué à capturer la vraie
nature de l’interopérabilité, l’approche de Baldoni et son équipe semble avoir connue un
grand succès. En effet, Ils ont réussit à proposer une représentation d’un protocole basée sur
l’échange de messages et les automates d’états finis tout en focalisant sur les propriétés
essentielles à la vérification de l’interopérabilité d’un ensemble de services. Ils ont définit un
‘’conformance test’’ permettant de garantir, a priori, l’interopérabilité d’un ensemble de
services en vérifiant les propriétés de chaque service singulier par rapport au protocole.
A la différence des travaux précédemment présentés ayant traités une interopérabilité liée à
l’aspect procédural, le travail de Montali [112] propose un langage de spécification de flux de
services permettant une vérification de l’interopérabilité des services qui est beaucoup plus
liée à l’aspect déclaratif. Ce langage est nommé DecSerFlow.
D’après Perrin [111], les auteurs indiquent que l’interopérabilité représente la solution de
plusieurs problèmes et citent comme exemple la composition de service qui implique le
problème de synthèse (i.e., comment coordonner les services pour atteindre un but donné).
Pour garantir l’interopérabilité, ils proposent l’analyse de compatibilité comme moyen de
vérifier si un client et un fournisseur interagissent correctement.
D’après Chopra [113], la chorographie et les services sont représentés par deux systèmes de
transition d’états et l’interopérabilité est définie comme un ensemble de critères qui doivent
être vérifié par le système de transition résultant de ces deux systèmes. Cette vision de
l’interopérabilité est en quelques sortes plus large que celle proposée par l’équipe de Baldoni.
Cependant, Baldoni et son équipe ont rejoint l’équipe de Chopra et ont réussit à formaliser les
deux notions interopérabilité et «conformance». Ces deux notions permettant de supporter des
agents autonomes (fonctionnements indépendants) et hétérogènes (indépendamment conçus)
40
qui offrent des services métiers et qui collaborent dans un engagement d’affaires. En
respectant l’autonomie, cette approche considère les choix que chaque agent possède, et
considère également comment ces choix peuvent être coordonnés de façon à ce que à chaque
fois, un agent mène et ses contreparties suivent (principe lead less, follow more). Aussi, en
respectant l’hétérogénéité, les auteurs caractérisent les variations dans les conceptions des
agents et montrent comment un agent peut conformer une spécification ou remplacer un autre
agent. Ce travail défie les approches qui l’ont précédé n’ayant pas réussi à traiter ce problème
avec des interactions multi-parties.
De plus, des opérations edit avec lesquelles il est possible de changer la conception d’un agent
afin d’assurer sa «conformance» avec les autres ont été introduites. Ce travail a été récemment
critiqué dans [114] par deux de ses auteurs.
5.2. Synthèse
A l’image de cette étude, il est clair que plusieurs travaux de recherche ont exploité
l’approche agent pour l’interopérabilité des services.
La définition de l’interopérabilité d’après Baldoni est très proche de la notre en se basant sur
la notion de protocole d’interaction d’un SMA. Ce travail propose une approche de la
vérification a priori de la conformité d'un processus d'affaires à un protocole, qui est basé sur
la théorie des langages formels et garantit l'interopérabilité des pairs où la conformité est
prouvé pour chacun d’eux dans une chorégraphie.
Par contre le travail de Perrin et al. proposent l’analyse de compatibilité comme moyen de
vérifier si un client et un fournisseur interagissent correctement et donc interopére.
Cependant, Chopra et al. propose une vision de l’interopérabilité est en quelques sortes plus
large que celle proposée par l’équipe de Baldoni.
En effet Chopra et al.partent de la définition de l’interopération existante dans la littérature
qui est : «l’interopération signifie travailler ensemble», puis constatent que dans la plupart des
travaux de recherche, la notion d’interopérabilité n’a pas pris un pas vers la tendance
d’interopérabilité de composants actifs.
Ils concluent qu’il serait intéressant de traiter des systèmes logiciels où les composants
représentent des partenaires business. Les auteurs proposent la notion de «Commitment
alignment» qu’ils définissent comme une interopérabilité de haut niveau (niveau business)
appropriée aux engagements business. Ils font appel au paradigme agent pour fournir une
notion d’interopérabilité qui supporte la flexibilité des engagements de services. En effet, ils
traitent les composants actifs comme des agents autonomes qui collaborent pour réaliser un
engagement service.
Dans notre travail, nous proposons un protocole d’interaction d’un SMA pour assurer
l’interopérabilité. Ce PI est défini en passant à partir de descriptions semi-formelles des PI,
41
vers des spécifications formelles en pi-calcul. De cette maniére, nous nous assurons que les
agents interopérent d’une maniére correcte vérifiée à priori. Dans notre approche, nous
considérons que l’intégration comme un concept générique incluant l’interopérabilité (en se
basant sur le principe de Vernadat [86]) tout en nous focalisons sur le concept d’intégration.
6. Différents aspects d’intégration

Il peut exister plusieurs approches permettant d’appréhender le problème d’intégration.
Principalement, nous pouvons distinguer quatre types fondamentaux. Il s’agit respectivement
en fonction de leur degré de complexité, de l’intégration de données, de processus, des
interfaces et des applications [115].
6.1. Intégration de données
C’est la forme la plus simple de l’intégration. Elle apparaît au niveau des bases de données.
D’une part, elle est assurée par duplication des copies d’une partie ou de toute la base de
données dans une ou plusieurs applications. D’autre part, l’intégration s’effectue par le
transfert des données, en utilisant des outils pour permettre aux données d’émigrer d’une
application à une autre. Ce transfert de données est généralement réalisé par ETL (Extract,
Transform and Load) [116]. ETL est un moteur qui extrait, transforme, épure puis charge les
données à partir de différentes applications vers des entrepôts de données. Il est aujourd’hui la
solution la plus préconisée dans l’intégration des données.
6.2. Intégration des applications
L'intégration d'applications (AI : Application Integration) porte sur l'interconnexion

d'applications hétérogènes, le plus souvent développées de façon indépendante et voire de
façon incompatible [117]. L'AI permet principalement de faire communiquer tout type
d’applications (CRM - Customer Relationship Management, ERP -Entreprise Ressource
Planning, SCM - Supply Chain Management, etc.), ce qui peut constituer des enjeux énormes
notamment pour les grosses entreprises qui disposent d'une masse importante d'applicatifs.
Sur le terrain, l'AI s'affiche par une multitude de produits commerciaux portant des logos
assez variés tels que EAI ou l’ESB (Business Work de Tibco, Integrator de Mercator, e*Gate
Integrator de SeeBeyond, Websphere d'IBM, Biztalk de Microsoft, Businessware de Vitria,
Intégration Server de WebMethods, EntireX de SoftwareAG, XMLBus d'Iona, Sonic ESB de
Sonic Software, etc.) [118] [119], et dont l’objectif est de permettre de rationaliser et fluidifier
le système d’information afin de le rendre plus flexible et plus réactif.
42
6.3. Intégration des processus
C’est la forme la plus complexe de l’intégration. Elle sert à rendre valable une application
dans le contexte d’une autre sans la dupliquer. Elle permet aussi de construire de nouveaux
processus métier à base des applications et progiciels existants. Ceci crée de nouvelles
opportunités pour l’organisation à moindre coût. Les données circulant dans la nouvelle
organisation sont accédées et maintenues selon une logique de métier (business logic) qui a
des règles et une sécurité de données. Ces données ne sont plus simples mais des objets métier
(BOD : Business Object Document, ex : bon de commande) qui portent déjà un sens [120].
Grâce à cette forme d’intégration, les nouveaux processus métier qui les manipulent sont
créés.
L’intégration du système d’information passe par l’intégration des briques le composant étant
présent à un moment donné. Aujourd’hui, la brique élémentaire du SI est l’application. C’est
donc tout logiquement que l’intégration du SI est considérée comme l’intégration des
applications qui le composent. Néanmoins, il ne suffit pas de connecter les applications entre
elles selon les besoins en information de telle ou telle application pour dire que l’on fait de
l’intégration de SI. Il ne faut pas prendre l’application comme un élément stable et autonome
qu’il faudrait connecter à d’autres éléments stables et autonomes. Il faut plutôt intégrer ce
pourquoi les applications ont été conçues. Il faut donc revenir à leur processus de conception
afin de définir l’objet de l’intégration de SI. Pour cela, dans la section suivante nous
présentons quelques approches pour l’intégration des applications.
7. Quelques approches pour l’intégration des applications
Nous présenterons quelques technologies d’intégration d’applications en soulignant la

manière dont elles facilitent les connexions aux applications. Chaque partie comportera une
présentation de ces technologies et leurs principaux composants. Ensuite leurs avantages et
leurs limites seront exposés.
7.1. Workflow et serveurs d’application
Le workflow et les serveurs d’applications sont deux composantes importantes pour

l’intégration des processus métiers : la première gère la circulation des documents échangés
par les différents protagonistes impliqués dans le processus, tandis que les serveurs
d’applications fournissent les ressources dont on a besoin pour traiter les processus répartis
[121]. Dans cette partie, nous verrons que même s’ils n’ont pas les mêmes buts, le workflow
et les serveurs d’applications partagent la même évolution. Le workflow peut être défini
comme étant " l’automatisation, totale ou partielle, d’un processus métier, dans lequel les
tâches passent d’un participant à l’autre pour être effectuées, selon un ensemble de règles
procédurales ". Il organise les processus métiers de deux façons : il définit l’ordre dans lequel
43
les tâches doivent être accomplies, et stipule les étapes et les points de contrôle où
interviennent des êtres humains. Les solutions workflow offrent en général les avantages
suivants :
• Reporting : Il gère les processus en mesurant leur durée, leur taux de réussite, etc.
• Identification des problèmes : Ils fournissent en cas de problème un mécanisme d’alerte
au gestionnaire du processus.
• Simulation : elle offre un outil de simulation pour aider l’entreprise à prendre des
mesures afin de continuellement améliorer ces processus. La force des solutions
workflow réside dans leur grande faiblesse : elles sont conçues pour travailler avec des
humains (c’est-à-dire avec les documents qu’ils ont créés) et non pas avec des systèmes
d’information de l’entreprise. En d’autres termes, ils n’ont pas étés conçus pour
intégrer des applications à un processus [121] [122].
D’un autre coté, les serveurs d’applications sont utilisés pour centraliser les processus des
applications sur des machines plus puissantes. Ils fournissent des outils et un environnement
pour développer et faire usage d’applications réparties.
En outre, les serveurs d’applications deviennent de plus en plus importants pour l’intégration
des processus métiers des entreprises, car ils présentent les avantages suivants :
• Ils offrent un mécanisme d’intégration par composants, c'est-à-dire que les composants
écrits avec des langages différents sont compatibles via des interfaces standards telles
que EJB ou CORBA [123].
• Ils offrent des services relatifs au temps d’exécution. Ces services recouvrent la gestion
des transactions, celle des objets, celle des sessions et celle des événements et des
pannes.
• Ils offrent une plateforme fiable, cette dernière offre des services comme la gestion des
transactions particulièrement adaptés à l’IAE (Intégration d’applications d’entreprise)
et à ses propres services comme le routage intelligent des messages. Les serveurs
d’applications ont tendance à être excessivement complexes à utiliser. La plupart des
constructeurs, comme IBM avec WebSphere [125], offrent d’ailleurs une palette de
services afin d’aider les entreprises à optimiser leur utilisation. Et, comme c’est le cas
pour des solutions workflow, il manque aux serveurs d’applications, des fonctions
nécessaires à l’intégration d’applications comme la transformation des formats et le
routage intelligent des données.
7.2. Applications basées sur un échange des messages
Ce type d’applications est apparu assez récemment et utilise les technologies de messages
inter-applications (ou MOM pour Message Oriented Middleware). En général, les solutions
MOM fonctionnent en faisant circuler les messages d’une manière asynchrone d’un
44
programme à un autre ou à plusieurs programmes. Contrairement à ORB et RPC, MOM

considère que la couche de transport n’est pas fiable, comme cela se produit lorsque les
programmes doivent communiquer via un réseau local ou Internet.
Dans le cadre de l’intégration d’applications, un type particulier de MOM, connu sous le nom
de pub/sub (publier/souscrire), convient le mieux à la BPI (pour, Business process
Integration). Avec pub/sub, les programmes souscrivent à un sujet défini par le développeur
[126].
Dans ce cas, les programmes peuvent aussi publier des messages relatifs à un sujet donné.
Une fois qu’un programme a souscrit à un sujet, le programme recevra, en temps réel, tous les
messages publiés sur le sujet en question. Ce système est particulièrement adapté à la BPI
étant donné qu’il permet la livraison de messages en temps réel à un grand nombre de clients.
Cela est particulièrement utile dans un cadre de collaboration où l’automatisation du
mouvement des données entre les applications et des processus métiers demande une livraison
immédiate des messages. Mais pub/sub n’est pas toujours la solution idéale. Dans le contexte
de l’IAE, il existe certaines appréhensions sur son efficacité en tant que solution au système
d’envoi des messages. Un autre problème avec MOM est celui de l’interopérabilité [127]. En
effet un MOM est généralement implémenté comme un protocole propriétaire de bas niveau,
ce qui signifie que l’implémentation est souvent incompatible avec d’autres implémentations.
7.3. Adaptateurs et connecteurs
Dans le cadre de l’IAE, il y a deux façons d’intégrer les applications : une intégration invasive
et une intégration non invasive. Une intégration invasive (c’est-à-dire une modification des
interfaces) n’est ni souhaitable ni possible avec un grand nombre de systèmes d’origine et de
progiciels. Pour cette raison, une intégration non invasive constitue la façon la plus courante
d’aborder le problème. Néanmoins, lorsqu’on veut connecter deux systèmes, l’API du premier
système doit au moins être adaptée pour convenir au modèle de programmation de l’autre
système, et les données doivent être transformées pour être échangées entre les deux modèles
de données. Par conséquent, nous avons besoin d’adaptateurs et de connecteurs [118] [119].
Dans la plupart des solutions IAE, il existe des adaptateurs et des connecteurs pour les
applications les plus couramment utilisés en entreprise telles que celles de SAP, Siebel et
Oracle. Parce que ces connecteurs sont pré-installés, ils permettent aux applications d’être
connectées rapidement, nécessitant ainsi un effort de développement minime. Mais tous les
adaptateurs/connecteurs ne peuvent pas être pré-installés pour tous les systèmes disponibles :
les entreprises doivent souvent développer leurs propres adaptateurs et connecteurs. Pour ce
faire, elles auront peut être besoin de concevoir l’application de façon à ce qu’elle puisse
gérer elle-même les services comme la sécurité, les transactions, la gestion des connexions,
etc. Cela prend beaucoup de temps, coûte cher et en conséquence le travail est souvent bâclé
[128].
45
7.4. Synthèse
Dans cette section nous avons vu qu’une sélection faite avec soin des composants principaux
d’une solution IAE pouvait conduire à un couplage inférieur lors de l’intégration entre
systèmes. Néanmoins, nous remarquons la difficulté et le temps qu’il faut pour: mettre en
place les systèmes de messagerie et développer les adaptateurs d’applications requis.
De nos jours, les entreprises qui utilisent les solutions IAE sont conçues pour relier
durablement, via des connexions discrètes, des applications souvent monolithiques. Or, pour
la gestion des processus métiers, les organisations ont besoin de technologies qui soient très
flexibles et capables d’intégrer rapidement, des systèmes à travers toutes sortes de barrières
technologiques, quelle que soit la durée d’existence des liens. Ce qui a amené la communauté
des chercheurs vers le standard service web. C’est une collection de standards basés sur XML,
fournissant un moyen modulaire et dynamique de transmettre l’information entre les
applications.
8. Principaux champs d’intégration des applications

Tout d'abord, précisons que l’intégration des applications ne traite pas de la communication à
l'intérieur d'une application, qui est du ressort du génie logiciel, mais elle traite plutôt des
échanges entre les applications. Ainsi, le champ d'intervention de l’intégration des
applications est le domaine d'applications. En fonction du périmètre couvert par les échanges
inter-applications, il est possible de distinguer essentiellement deux champs d'intégration des
applications: l'intégration intra-entreprise et l'intégration extra-entreprise (figure 2.2) [128]
[129].
Figure.2.2 – Champs d’intégration d’applications [27].
L'intégration intra-entreprise, qui est le plus souvent désignée par le sigle A2A (Application to
Application), ou le sigle EAI, est une intégration qui se limite aux applications internes à
l'entreprise. Tandis que l'intégration extra-entreprise étend la précédente pour inclure
l'intégration des applications des partenaires et des fournisseurs (B2B - Business to Business).
Pour simplifier, nous supposons que le B2B inclut le B2A - Business to Administration), ainsi
46
que l'intégration des clients (B2C - Business to Customer intégration), ce qui permet de
s'insérer dans le cadre du commerce électronique.
9. Exemple de domaine d’application: le E-gouvernement
Nous exposons dans cette section les caractéristiques et les concepts liés au domaine de l’e-
gouvernement qui est notre domaine d’application. Une étude de cas lié à ce domaine sera
présentée dans le chapitre 5 de ce manuscrit.
9.1. Définitions
Il existe plusieurs définitions du terme «e-gouvernement », nous retiendrons quelques unes

parmi elles.
Selon Dempsy, le e-gouvernement est: «l'usage des Technologies de l’Information et de

la Communication (TIC) pour transformer le gouvernement en le rendant plus accessible
aux citoyens, plus efficace et plus responsable » [130].
Cette définition présente une conception particulière de l’impact des TIC sur le nouveau
rôle de l’état (accessibilité, efficacité et responsabilité). L’accessibilité n’implique pas de
mettre plus d'ordinateurs sur les bureaux des fonctionnaires du gouvernement. Elle s’intéresse
plutôt aux rapports entre les fonctionnaires du gouvernement et le citoyen. Le e-gouvernement
doit permettre en premier lieu un accès en ligne (sur Internet) à plus d’informations tels que
les lois, les décrets, les circulaires, les formulaires ainsi que les données économiques ou
scientifiques. Il doit aussi encourager l'engagement civique en permettant au citoyen
d’interagir plus commodément avec les fonctionnaires du gouvernement, en consultant et en
créant des documents exigés dans une procédure administrative électroniquement. Enfin, cette
définition stipule la responsabilité croissante du gouvernement en rendant les opérations plus
transparentes, en réduisant les occasions de corruption et de fraude et en permettant aux
petites entreprises ainsi qu’aux communautés rurales d’avoir accès à plus d'information.
Une deuxième définition proposée par Johnston dans le cadre de la conférence
internationale GOVIS, présente le e-gouvernement comme étant : « un processus qui permet
l’utilisation de l’Internet pour : fournir des services aux clients et aux entreprises, pour
permettre aux organisations du gouvernement de connecter les employés, les fournisseurs et
les clients et pour transformer les opérations du gouvernement en incluant aussi les relations
gouvernement – gouvernement » [131].
Dans cette définition, l’accent est mis sur deux concepts principaux : les e-services et les
relations entre le gouvernement et ses différents partenaires. Un e-service correspond à
l’échange dématérialisé de formalités entre les autorités publiques (ministères, services
déconcentrés, organismes publics …) et leurs partenaires et usagers. Autrement dit, c’est un
47
service auquel un citoyen peut accéder à travers une trousse de clés numériques telle que la
carte à puces pour effectuer par exemple une formalité de type : calcul ou simulation des
impôts, assistance en ligne, suivi d’un dossier personnalisé, etc. Nous notons ici l’importance
des e-services pour la protection des données personnelles du citoyen, car l’accès au compte
personnalisé passe par des codes que seul le citoyen connaît.
Le deuxième et le troisième volet de cette définition précise que le e-gouvernement peut
être utilisé pour améliorer la communication entre l’administration et les citoyens (″A to C″,
c’est-à-dire Administration to Citizen), mais également la communication avec les entreprises
(″A to B″, c’est-à-dire Administration to Business), ainsi que la communication des
différentes administrations (″A to A″, c’est-à-dire Administration to Administration).
9.2. Interopérabilité dans le e-gouvernement
L’amélioration de l'interopérabilité entre les organismes publics et entre les organisations

publiques et privées est d'une importance critique pour rendre le gouvernement électronique
plus efficace [132,133]. La mobilisation de l'information électronique dans les organisations a
le potentiel pour moderniser et améliorer les échanges d'informations. L'échange
d'information actuel est cependant, souvent inefficace et source d'erreurs [134]. Les échanges
d'informations et de services sont fragmentés et complexes, tourmentés par les problèmes
techniques et organisationnels [135].
Pour que l’e-gouvernement soit réussi, il faut développer des opérations gouvernementales et
des services agiles, centrés sur le citoyen, responsables, transparents, efficaces et efficients
[136]. L'intégration des ressources d’information et des processus publics et donc
l'interopérabilité des systèmes d'information indépendants, sont indispensables pour atteindre
ces objectifs. Pourtant, la plupart des efforts d'intégration et d'interopérabilité sont confrontés
à de sérieux défis et limites.
L'interopérabilité est une propriété de la diversité des systèmes et des organisations qui leurs
permettent de travailler ensemble [137].
L'interopérabilité est la capacité des organisations gouvernementales pour partager des
informations et d'intégrer les processus métiers par l'utilisation des standards et des normes
de travail [138]. Lorsque l'information et les services sont fournis et acceptés entre les
systèmes et les organisations, nous dirons qu'ils inter-opérent.
Dans un sens étroit, le terme interopérabilité est souvent utilisé pour décrire les systèmes
techniques. Dans un sens plus large, les facteurs sociaux, politiques et organisationnels
influant les systèmes et les performances des systèmes doivent également être pris en compte.
Par exemple, les nouvelles technologies sont introduites dans les hôpitaux et les laboratoires à
un rythme toujours plus rapide, et beaucoup de ces innovations ont le potentiel d'interaction
synergique si elles peuvent être intégrées efficacement. Cependant, comme l'a souligné
48
Eckman et al. [134], l'échange d'information actuel de soins de santé est inefficace et source
d'erreurs. Dans la plupart des pays, il est en grande partie à base de papier et fragmenté (donc
trop complexe), et s'appuie souvent d’une manière archaïque sur la technologie de
l'information.
En même temps, les coûts de la santé augmentent de façon spectaculaire. Les erreurs de
livraison médicale sont associées à un nombre alarmant d'événements indésirables, parfois
mortelles. Une stratégie prometteuse pour inverser cette tendance est de moderniser l'échange
d'informations de santé, qui est, la mobilisation de l'information de santé électronique au sein
des organisations, au sein d'une région ou d'une communauté [134].
Toutefois, dans le cas des hôpitaux, il y a des limites à la libre circulation de l'information.
Les systèmes gèrent souvent des données sensibles sur des personnes, des relations, des
groupes et des organisations. La collecte et le partage de ces informations sont affectées par
des problèmes de confidentialité [135].
Alors que le gouvernement électronique se réfère à la prestation de services gouvernementaux
(informations, interaction et transaction) à travers l'utilisation des technologies de
l'information, une distinction peut être faite entre le front office et back office des
organisations de prestation de services publics. L'interaction entre les citoyens et les
fonctionnaires se produit dans le front office, tandis que les activités d'enregistrement et
d'autres ont lieu dans le back office. Cependant, Bekkers et al. [14] ont constaté que la
coopération back-office est un sérieux goulot d'étranglement dans l'administration
électronique en raison de problèmes d'interopérabilité différents.
Une action importante pour améliorer le partage de l'information est la standardisation des
systèmes d'information. Il est nécessaire de définir les normes de compatibilité avant d'être
adopté entre les systèmes [141]. Certains organismes devront modifier leurs procédés
techniques et organisationnels et des accommodements en réponse aux initiatives de
normalisation [142].
Une distinction doit être faite entre l'interopérabilité et l'intégration.
L'intégration est la formation d'une plus grande unité d'entités gouvernementales, temporaires
ou permanentes, dans le but de la fusion des processus et / ou le partage d'informations.
Tandis que, l’interopérabilité dans l'e-gouvernement se produit chaque fois que les systèmes
d'information indépendants ou hétérogène ou leurs composants qui sont contrôlés par
différentes juridictions, administrations, ou partenaires externes travaillent ensemble
(efficience et efficacité) d'une manière prédéfinie et convenue. L’interopérabilité dans le e-
gouvernement est la capacité technique pour l'interopérer dans le e-gouvernement [139].
49
10. Conclusion
Ce chapitre fournit une analyse des différentes notions liées à l’intégration et à

l’interopérabilité. Nous avons essayé d’étudier les différents outils permettant de réaliser
l’intégration et l’interopérabilité dans divers domaines et activités. Par la suite, nous nous
sommes orientés plus particulièrement vers le domaine d’application qui est le e-
gouvernement. Nous avons discuté certaines définitions clefs; ce qui nous a permis de donner
une définition synthèse qui exprime les différents aspects de l’interopérabilité dans le e-
gouvernement. En outre, nous avons déterminé les niveaux, les difficultés, les avantages, les
inconvénients, et les défis de l’interopérabilité des systèmes d’une manière générale. Pour
conclure, nous pouvons dire à partir de la synthèse de cette partie, que cet état de l’art d’un
point de vue organisationnel nous a permis de préparer le terrain pour l’étude du
développement de l’interopérabilité et de l’intégration.
50
Spécification d’un
protocole d’interaction
dans les e-services 3
1. Introduction
Après avoir dressé un état de l’art sur les différents concepts liés aux e-services, à savoir, les
services web et les systèmes multi-agents, ainsi que la présentation des formalismes semi-
formel (AUML) et formel (pi-calcul), nous essayons d’utiliser ces concepts pour pallier aux
limites de l’intégration et d’interopérabilité des processus métiers.
Dans ce chapitre, notre élément clé est le protocole d'interaction (PI) qui est une description
des comportements observables de différentes applications [25]. A travers ce PI nous
essayons d’intégrer des processus métiers en interaction.
Pour cela, nous définissons un PI efficace et qui peut être utilisé pour vérifier si une
application peut correctement jouer un rôle spécifique défini par ce PI. Pour cette raison, nous
présentons une cartographie complète et rigoureusement mise en exergue de constructions du
PI en passant du formalisme graphique AUML vers BPEL puis vers π-calcul.
BPEL est un langage puissant et expressif mais ne dispose toujours pas d'une sémantique
formelle largement acceptée pour toute la communauté du workflow. Il est donc difficile de
valider formellement l'exécution correcte d'implémentations de solutions exprimées en WS-
BPEL. Comme nous l'avons illustré dans le chapitre précédent, les algèbres de processus et en
particulier le pi-calcul, ont largement prouvé qu'ils étaient l'outil idéal pour spécifier
formellement l’intégration des processus métiers. Aussi, de vérifier certaines propriétés
inhérentes à cette interaction.
Dans le cadre de cette thèse, notre travail comporte deux contributions qui recouvrent les
principales étapes en commençant par la modélisation et la vérification du scénario
d’intégration et puis, nous exposerons l’exploitation et la gestion de l’interaction au moment
d’exécution.
51
Spécification d’un protocole d’interaction dans les e-services
2. Motivation
Les problèmes d'intégration et d'interopérabilité ne sont pas nouveaux car ils constituent des
domaines de recherche auxquels s'intéressent plusieurs communautés dont celle des systèmes
d'information, celle des bases de données, celle du génie logiciel, celle des systèmes
Workflows, etc. Plusieurs approches, standards et/ou technologies ont été proposés pour
résoudre ces problèmes.
Dans le cadre de nos travaux, nous considérons que l’intégration comme un concept
générique incluant l’interopérabilité (en se basant sur le principe de Vernadat [83]) tout en
nous focalisons sur le concept d’intégration.
En effet, il n’est pas sûr qu’une application, basée sur des services distants et interconnectés
par des réseaux, aboutira par la bonne intégration des processus à une application correcte.
En outre, il est nécessaire qu’au niveau local les agents soient capables de se comprendre, de
se répartir le travail. Ainsi dans cette section nous présentons certains mécanismes pour
faciliter la coopération entre agents. Notre objectif est de spécifier des propriétés et des
protocoles d’interaction SMA, vérifier leurs comportements et de les adapter pour intégrer
plusieurs applications.
Pour cela, nous allons définir un processus qui permet d’utiliser des protocoles d’interaction
cohérents et de réaliser une intégration correcte.
Dans le chapitre 1 section 7, nous avons présenté quelques travaux relatifs aux protocoles
d’interaction. Ces travaux ne spécifient pas une démarche complète pour l’ingénierie des PI
dans le cadre d’intégration d’applications ; c’est ce qui a attiré notre attention.
Cependant, certains chercheurs exposent et expliquent qu’une seule étape du processus
d’intégration. La première critique que nous pouvons apporter au travail de Kishore et al. [73]
est qu’aucune étape de validation n’a été présentée dans leur modèle.
Les travaux de El Fallah-Seghrouchni et Haddad [76] présentent seulement les étapes de
modélisation et de vérification. L’exploitation au moment de l’exécution des modèles
d’agents développés est complètement omise.
Dans ce chapitre, nous présentons une démarche de modélisation et de vérification basée sur
les PI.
Dans le cadre de cette thèse, notre travail comporte deux contributions qui recouvrent les
principales étapes en commençant par la modélisation et la vérification du scénario
d’intégration et puis, nous exposerons l’exploitation et la gestion de l’interaction au moment
d’exécution.
En effet, nous définissons par la suite une méthodologie permettant de passer à partir de
descriptions informelles des PI, vers des spécifications formelles en pi-calcul tout en se
focalisant sur la dynamicité des interactions.
52
3. Fondements de notre approche
Les organisations et leurs processus métiers sont de plus en plus dynamiques, distribués et
complexes. Ainsi, même un processus simple (par exemple, le traitement d'une commande)
peut nécessiter des transactions commerciales à travers les frontières de nombreuses unités
commerciales (service de livraison, service de vente, inventaire, etc) et déclenche des
interactions entre de multiples acteurs et applications logicielles [42].
En fait, l’automatisation de l'interaction entre plusieurs partenaires métiers offre un grand
potentiel d'optimisation en ce qui concerne la performance globale des processus métiers.
Toutefois, elle soulève aussi des défis à relever. Par exemple, les formats de messages
communs doivent être convenus et des séquences d'interaction attendues doivent être
clairement définies. En outre, les séquences d'échange de messages ainsi que des contraintes
de l'organisation doivent être capturés.
Par conséquent, les systèmes de gestion de processus métiers (BPMS) force les concepteurs
d'intégrer du code dédié dans le même champ d'application que la logique des processus
métiers. En outre, en dehors des mécanismes de corrélation pour le routage des messages pour
traiter les instances, BPMS acceptent les messages qui leur sont envoyés sans filtrage,
réduisant ainsi des quantités inutiles de code de sélection de message dans la définition de
processus. En résumé, la distinction entre les abstractions de processus et ceux de la
communication est floue dans les approches existantes.
BPMS prennent de l'ampleur grâce à l'émergence des standards services Web et multi-agents
pour la modélisation des systèmes. Les protocoles d'interaction (PI) ont été les premiers défi
de conception de systèmes multi-agents [25]. La communauté de l'agent a répondu en
développant Agent UML [36]; ce dernier est dédié aux agents et qui tentent de simplifier la
transition de génie logiciel à l'ingénierie des systèmes multi-agents. En revanche, BPEL4WS
est une norme de facto pour décrire une intégration des processus métiers (BPI) comme une
composition de services web. Dans le chapitre suivant nous explorerons la relation entre les
services web, les systèmes multi-agents en présentant une architecture basée agent.
Notre approche motive l'utilisation de PI qui est basé sur AUML/BPEL4WS pour la
modélisation BPI.
Ainsi, spécifier le comportement des différents agents du système, selon la perspective d’un
objectif collectif donné, revient à spécifier les interactions sous forme de protocoles, de rôles,
et éventuellement d’intentions.
Un PI représente la collaboration et la coordination de plusieurs rôles compatibles. Chaque
agent peut être impliqué dans une ou plusieurs de ces collaborations à différents moments de
son existence, en endossant différents rôles [25].
Pour une meilleure interactivité, la communication entre les processus métiers devrait être
gérée de façon appropriée. Le PI fournit un motif formel pour permettre cette réglementation.
53
Cependant, l'élaboration de protocoles efficaces pour être exécutés par des partenaires
autonomes est difficile. Semblable à des protocoles dans les systèmes traditionnels, le PI dans
les milieux ouverts basé sur le Web doit être spécifié rigoureusement afin que les partenaires
peuvent interagir avec succès. Cela pose le problème évident de vérifier que l'interaction des
processus métiers à respecter le PI.
En conséquence, notre préoccupation dans ce travail de recherche concerne l’intégration des
applications par les processus et l’interopérabilité à l’aide d’agents dits communicants, c’est à
dire qu’ils interagissent par l’envoi de messages, en utilisant un langage de communication de
haut niveau. Plus précisément, l’approche que nous proposons se focalise sur les protocoles
d’interaction qui constituent l’unité fondamentale du processus d’intégration [145].
Dans le chapitre suivant, un agent central utilise ces informations afin de coordonner avec les
autres agents de l’organisation. Les PI devraient être publiés et partagés par cet agent pour des
éventuelles réutilisations.
4. Définition du protocole d’interaction
La plupart des processus internes des organisations ont été simplifiés et optimisés, tandis que
les processus externes n'ont que récemment été l’objet des analystes et des fournisseurs de
middleware informatiques.
Selon Kishore, l'intégration statique des processus inter-organisations ne peut plus répondre
aux nouvelles exigences orientées client, la flexibilité et la dynamique de la coopération [73].
L'utilisation de protocole d’interaction pour définir les processus permet une plus grande
autonomie des organisations. De cette façon, le PI fournit un haut niveau d'abstraction dans la
modélisation des processus publics. En revanche, les scénarios d'intégration et
d’interopérabilité impliquent généralement des processus métiers distribués qui sont
autonomes dans une certaine mesure, d'où l'importance de la modélisation basée sur le PI. Ce
dernier, est un moyen utile pour structurer l'interaction communicative entre les partenaires,
en organisant des messages dans des contextes pertinents et de fournir un guide commun pour
toutes les parties. Formellement, un PI est défini comme un triplet:
PI = < IdP, A{n}, M >, tel que:

• IdP est l’identificateur du PI
• A{n} est l’ensemble des clauses d’agents tel que A= a1, a2, . . . , an (n > 1) tel que : ai =
(r, id) où: r: est le rôle de l’agent ai et id: est l’identificateur de l’agent ai.
• M= {S U C} est l’ensemble des messages simples (ou/et) complexes échangés.
Définition 1 (messages simples): le message simple S est défini comme suit:S =<s,r,a,con>,
où:
- s,r ‫ א‬A (s est l’agent émetteur et r est l’agent récepteur)
54
- a ‫ א‬FIPA /ACL Acte de Communication (tel que: request, inform , . . .)

- con ‫{א‬Synchrone/Asynchrone message, timeout, . . .}
Définition 2 (messages complexes): un message complexe (C) est construit à partir de simple
messages en utilisant des opérateurs: C = S1 op S2 . . . op Sm, où: m>1, op‫{א‬XOR,OR,AND}
Dans l’approche que nous proposons, le niveau d’abstraction choisi se restreint aux actions de
communication observables entre les différents processus métiers.
Dans les sections suivantes, nous mettons en exergue les étapes de transformation nécessaire
pour notre protocole d’interaction afin d’obtenir un « PI » qui soit correct.
5. Etapes de transformation du protocole
Le protocole d’interaction est soutenu par les relations étroites entre les concepts proposés par
WS-BPEL et ceux offerts par AUML.
AUML est un langage visuel facilement compréhensible qui permet d'exprimer la structure de
haut niveau des protocoles d'interaction. Tandis que, WS-BPEL est un langage XML assez
complexe approprié pour exprimer non seulement la structure de haut niveau des processus
métiers impliquant un ensemble de services web, et par conséquent les interactions entre eux,
mais également des détails sur l'échange de messages, les opérations demandées aux services
web. WS-BPEL est donc assez puissant pour représenter toutes les informations contenues
dans les diagrammes AUML.
En raison de cette correspondance étroite et les relations existantes entre les agents et les
services Web, nous proposons d'utiliser AUML pour représenter les PI et BPEL4WS pour
spécifier et de les publier sur le web.
Cependant, grâce à BPEL4WS, notre PI est devenu un système modulaire, permettant la
publication des spécifications des interactions entre les différents partenaires. Sachant que
dans notre proposition, ce sont les actions de communication observables qui nous interessent.
Quand les protocoles sont utilisés dans des environnements ouverts, tels que l'Internet, ils
doivent être exécutés par des agents qui se comportent plus ou moins d’une manière
autonome et dont la structure interne n’est pas connue. Par conséquent, il existe un risque que
les agents participants ne parviennent pas à se conformer au protocole [143].
Pour cela, l'utilisation des méthodes formelles est importante car assurer l'exactitude d'un des
protocoles complexes est rarement possible via d'autres approches de conception. L’algèbre
des processus est une méthode formelle de haut niveau adaptée à la conception des PI en
raison de leur capacité à exprimer la concurrence, le non-déterminisme et les concepts du
système à différents niveaux d'abstraction (voir chapitre 1 section 6.4).
55
Il est nécessaire d'avoir une sémantique opérationnelle précise des langages de description
comportementale de ces applications. D'où l'intérêt de notre approche et de l'apport d'une
sémantique opérationnelle pour le langage WS-BPEL. Cette sémantique opérationnelle
permet alors d'appliquer des méthodes formelles pour vérifier certaines propriétés
comportementales du système étudié.
A travers cette explication, notre approche consiste en la formalisation de l’intégration
d’applications par les processus à l’aide de SMA dits communiquants (les agents qui inter
agissent par l’envoi de messages) [145]. Dans notre thèse cette formalisation se réalise en
deux étapes (voir figure 3.1):
• Niveau conceptuel : la modélisation et la vérification du scénario d’intégration.
• Niveau opérationnel : l’exploitation et la gestion de l’interaction au moment de
l’exécution.
Figure.3.1 – Etapes de translation du protocole d’interaction.
6. Transformation du diagramme d’interaction vers la spécification

BPEL4WS
Dans cette section, nous abordons la première étape de transformation de notre processus
proposé. A savoir, le passage de AUML vers BPEL4WS. L’intérêt de cette transformation a
été abordé au niveau de la section 3 de ce même chapitre. La spécification BPEL4WS fournit
à la fois des structures de contrôle à base de bloc et de graphes, le rendant capable de
représenter une grande variété de flux de contrôle.
Ce langage peut être utilisé pour décrire les processus métiers exécutables et les processus
abstraits. Ces derniers, sont utilisés pour créer des spécifications de comportement consistant
56
en l’échange des messages visibles mutuellement entre les parties de transactions exécutant
un protocole d’interaction.
Dans notre cas, une spécification BPEL4WS décrit un processus métiers en indiquant les
participants, les services qu’ils doivent mettre en œuvre pour appartenir au processus métier,
et le flux de contrôle du processus. Par exemple, la section <partners> définit les différentes
parties qui participent au processus. Chaque partenaire se voit attribuer un type de lien de
service et le rôle qu'il jouera dans la liaison de service. La section <variables> permet la
définition des variables utilisées par le processus. Le processus de définition du processus
métier se fait après la section sur les gestionnaires d'erreur et avant la balise de fin du
processus. Un processus métier est défini en utilisant des constructeurs d’activités de
BPEL4WS (séquence, flow, while, switch, ... etc.).
Diagramme d’interaction Formalisme BPEL4WS

<partners>
P P <partner name = ’’P1 ‘’/>
<partner name = ’’P1 ‘’/>
</partners>
Role

<flow>
M1 <reply name = ‘’M1’’>
…..
</reply>
…..
</reply>
AND-Split </flow>

<switch>
M1 <case cond1>
<reply name = ‘’M1’’>
…..
</reply>
</case>
M2 < case cond2>
…..
OR-Split </reply>
57
<otherwise>
….
</otherwise>
</switch>
M1 <if condition = ‘’cond-bool’’>

….
</reply>
….
XOR-Split </reply>
</if>

<invoke name = ‘’P2’’

M Partner = ‘’P2’’
inputVariable = ‘’Request’’
outputVariable = ‘’Résultat’’
….
Message synchrone </invoke>

M <while condition = ‘’cond-bool’’>

<receive name = ‘’M’’
Partner = ‘’P2’’
…..
</while>
Itération

M
<sequence>
<receive name = ‘’M’’
Partner = ‘’P2’’
Séquence asynchrone ….
</receive>

Tableau.3.1 – Passage du diagramme d’interaction vers BPEL.
58
Beaucoup de spécifications qui caractérisent les processus abstraits de BPEL4WS, les rendent
très adaptés pour représenter des protocoles d'interaction et de correspondre d'une manière
précise à celles qui caractérisent AUML. Le tableau 3.1 décrit la traduction de AUML vers
BPEL4WS.
Dans ce qui suit, nous expliquons le passage de AUML vers BPEL4WS.
6.1. Messages échangés
L’échange de messages peut être mis en œuvre par l’exécution des activités « invoke » et
« receive » que WS-BPEL offre. Invoquer une opération d’un service fourni par un partenaire
(spécifié par le lien partenaire) peut être soit une opération de type requête / réponse
synchrone ou une opération unidirectionnelle asynchrone. Une invocation asynchrone
nécessite seulement le message d'entrée de l'opération, car il ne s'attend pas à une réponse
dans le cadre de l'opération. Tandis qu'un appel synchrone nécessite à la fois un message
d'entrée et un message de sortie.
Dans notre cas, le processus invoke représente une communication synchrone où un
expéditeur envoie une requête et attend la réponse.
6.2. Représentation des messages complexes
Dans la section précédente, nous avons défini un message complexe d’un PI comme étant un
élément qui est construit à partir de simple messages en utilisant des opérateurs tel que: C =
S1 op S2 . . . op Sm, où: m>1, op‫{א‬XOR,OR,AND}
Dans l’approche que nous proposons, le niveau d’abstraction choisi se restreint aux actions de
communication observables entre les différents processus métiers.
Les messages complexes de type ANDsplit, OR-split et XOR-split de AUML sont représentés
respectivement par les processus BPEL4WS par <flow>, <switch> et <i f > (voir tableau
3.1).
6.2.1. Activité « switch »
L'activité « switch » se compose d'une liste ordonnée de une ou de plusieurs branches

conditionnelles définies par des éléments de cas « case », suivie éventuellement par une
branche contraire « otherwise ». Les branches relatives à « case » de l'activité « switch » sont
considérées dans l'ordre dans lequel ils apparaissent.
La première branche dont la condition est vérifiée est prise et fournit l'activité réalisée par le
« switch ». Si toutes les conditions des branches ne sont pas vérifiées, alors la branche
« otherwise » est prise en compte. L'activité de « switch » est terminée lorsque l'activité de la
59
branche sélectionnée est terminée à son tour. Donc, « switch » permet de modéliser le "ou
inclusif" où zéro, un ou plusieurs messages peuvent êtres envoyés en même temps.
6.2.2. Activité « if »
Dans la sémantique de BPEL4WS l'activité « if » consiste en une liste ordonnée d'un ou

plusieurs branches conditionnelles définies par « if » ou « elseif », suivie éventuellement
d'une autre branche « else ». Le « if » et « elseif » de l'activité « if » sont considérés dans
l'ordre dans lequel ils apparaissent. Le dernier processus BPEL4WS (le <if >) exprime qu’un
et un seul message peut être émis à la fois. Le choix peut être effectué entre différents
messages.
6.2.3. Constructeur « flow »
Le constructeur « flow » de BPEL fournit de la concurrence et de la synchronisation. L'effet

sémantique fondamental est de regrouper un ensemble d'activités dans un flux pour permettre
la concurrence. Un « flow » se termine lorsque toutes ses activités sont terminées. La
réalisation d'une activité dans un « flow » inclut la possibilité qu'elle sera ignorée si sa
condition se révèle fausse. Ainsi, l'utilisation la plus simple de « flow » correspond à une
construction de concurrence imbriquée. Nous pouvons dire que le processus flow est utilisé
afin de modéliser que plusieurs messages peuvent êtres envoyés en même temps, ce qui
correspond au mécanisme du ANDsplit de AUML.
6.3. Services web et élément partenaire
Dans cette partie, nous essayons d’établir une correspondance entre AUML et BPEL dans le
cas où un ou plusieurs partenaires de l’interaction est un service web.
Dans AUML nous avons utilisé le diagramme d’interaction qui est une extension du
diagramme de séquences d’UML. La présentation sous forme de diagramme d’interaction
apporte une certaine intuitivité. Ceux ci expriment l'interaction en se centrant sur l'ordre ou
séquence des messages échangés par des entités appartenant à deux ou plusieurs classes, dans
une instance d'interaction. Pour pouvoir modéliser l’aspect dynamique intra agent qui est
absent en AUML, le langage BPEL4WS est introduit.
Nous utiliserons le partnerLinks qui fournit un canal de communication aux services Web
distants utilisés dans le processus BPEL. Chaque partnerLinks est typé par un
partnerLinkType et précise le rôle que joue un partenaire dans un portType.
Aussi, les variables sont utilisées pour stocker les messages d’interaction avec les services
Web partenaires et les données internes du processus BPEL. Le type d’une variable est
60
référenciée par un type de message dans un document WSDL ou un type de données défini
dans un schéma XML.
Le partenaire de WS-BPEL caractérise la relation de conversation entre deux services en
définissant les «rôles» joués par chaque service dans la conversation, et en spécifiant le
portType fourni par chaque service pour recevoir des messages dans le contexte de la
conversation. Le rôle du processus de l'organisation elle-même est indiqué par l'attribut
myrole et le rôle du partenaire est défini par l’attribut partnerRole.
Dans la suite, nous mettrons en exergue le mécanisme de passage de BPEL vers le pi-calcul.
7. Passage de WS-BPEL vers le pi-calcul
Après la présentation du passage de AUML vers WS-BPEL, dans cette section nous étudions
la traduction du WS-BPEL vers le pi-calcul. Nous nous basons sur les travaux de Lucchi et
Mazarra [144]. Cependant nous divergeons de cette approche de la manière suivante :
• Nous ne considérons pas les aspects transactionnels,
• Nous introduisons les opérateurs et concepts non traitées dans le travail cité
• La boucle <while> qui est un élément fondamental pour la construction des processus
métiers et qui n’a pas été occulté dans [144].
Pour faciliter la lecture de la traduction, nous utilisons la syntaxe abstraite suivante pour
représenter les différents éléments du langage WS-BPEL.
Pour chaque primitive WS-BPEL nous fournissons dans ce qui suit sa traduction en pi-calcul.
61
7.1. Processus nul
L'élément <empty/> du WS-BPEL est exprimé par l'intermédiaire du processus nil du pi-
calcul (c’est un processus qui ne fais rien) :
<empty/> 0 (processus nil

inactif)
7.2. Réception
Si nous supposons une information i et un partenaire r alors, la réception d'une information i

du partenaire r est traduite par une réception sur le canal x qui représente l'opération WS-
BPEL :
Où est la représentation qui inclut le canal de réponse r et l'information reçue i.
7.3. Emission
Un élément <invoke> du BPEL qui consiste en une émission de l'information représentée par
o au partenaire r est traduite par une émission sur le canal x qui représente l'opération WS-
BPEL.
62
7.4. Messages complexes
Un message complexe est composé à partir des messages simples (primitifs) par le moyen
d’opérateurs.
Dans le cas des PI, il existe trois types de messages complexes : ou-exclusif, ou-inclusif et
concurrent représentés respectivement par : <if>, <switch> et <flow>. Dans ce qui suit, nous
allons présenter la traduction de ces trois types de messages.
7.4.1. Condition
Il s’agit du cas des messages de type ou-exclusif , où un et un seul message peut être envoyé à
la fois. Le choix peut être fait entre différents messages. Ce type d’interaction est représenté
par la section <if>/<pick> de BPEL4WS.
L'élément de condition du langage WS-BPEL s'exprime aisément grâce à son équivalent dans
pi-calcul :
WS-BPEL autorise l'usage des <if> imbriqués grâce à l'élément <elseif>.
7.4.2. SWITCH
La composition conditionnelle dans BPEL suit une approche de déclaration de cas. Nous
présentons le cas de base de « n » alternatives avec une condition booléenne « x ». Cette
expression sera naturellement codée par l'instruction conditionnelle de notre algèbre comme
suit :
63
7.4.3. Composition parallèle
Il s’agit du cas où plusieurs messages sont envoyés en même temps. Ce cas est contrairement
différent aux messages de types OU (inclusif ou exclusif).
Un aspect crucial des langages workflow pour les services Web c'est la possibilité de
composer de nombreux processus métiers en parallèles. La simultanéité permet la polyvalence
nécessaire par le scénario, mais introduit quelques complications sémantiques de première
importance.
L'élément de la composition parallèle est ainsi spécifié grâce à l'opérateur | :
Il est à noter que WS-BPEL permet l'utilisation de liens (links) qui expriment des
dépendances de synchronisation entre les activités. Cependant ces dépendances peuvent être
exprimées en utilisant uniquement les éléments de base du pi-calcul. Le concepteur qui désire
malgré cela utiliser ces liens devra les inclure manuellement dans le code généré.
7.5. La boucle « While »
La boucle d’une partie de la spécification BPEL4WS est représentée par la section <while> et
une expression de condition.
Dans le cas des PI, les boucles sont formellement spécifiées en pi-calcul en utilisant la
récursivité. Nous les formalisons dans ce qui suit :
64
L'activité contenue dans un élément <while> s'exécute un nombre arbitraire de fois en

fonction de la condition spécifiée. La traduction d'un élément <while> est donnée par
l'utilisation d'une définition paramétrique récursive.
7.6. Séquence
Des informations de synchronisation peuvent s'avérer nécessaires pour réaliser proprement

une séquence de deux processus.
Soit sequence (A1,A2), la composition séquentielle de l’activité A1 et A2. La translation de
cette activité est :
À
ce
sta
de,
il y
a
un
point subtil qui mérite plus d'attention. Comme mentionné précédemment, le séquençage du
BPEL n'est pas un opérateur de liaison comme le π-calcul.
En particulier, les variables scopes déduisent différents comportements sémantiques par
rapport à la liaison habituelle de l'algèbre de processus.
Le problème se pose lorsque nous combinons successivement deux activités qui comprennent
certains noms communs. Dans ces cas, le codage nécessite plus d'attention. Pour cette raison,
nous ne pouvons pas simplement déclencher la deuxième activité si la première n’est pas
encore terminée, mais nous avons besoin de passer des informations supplémentaires afin de
lier les noms libres de la deuxième activité.
65
Dans cette thèse, nous revendiquons que toute déclaration d'essayer d'assimiler les workflow
comme les langages BPEL devrait être soigneusement analysés et ont besoin d'un examen
plus approfondi où les considérations théoriques jouent un rôle central.
En conséquence, les règles développées dans cette section permettent de couvrir tous les
composants BPEL4WS que nous avons utilisés pour spécifier les protocoles d’interaction.
Après l’explication des deux étapes de traduction du PI, nous terminerons le processus de
transformation par l’étape de vérification et de validation du PI.
8. Spécification des propriétés du PI
Le processus de vérification et de validation permet de s’assurer qu’une conception respecte

bien les spécifications. La vérification confirme que le produit correspond aux spécifications
le définissant et que vous l’avez conçu comme il se devait être. La validation confirme que le
produit, tel qu’il est prévu, correspond à l’utilisation attendue et que vous avez conçu le
produit approprié.
Cependent, un protocole invalide ne pourra pas garantir une interaction fiable. C’est pourquoi
il est important d’analyser et de valider les protocoles d’interaction pour prévoir et prévenir
s’ils sont susceptibles de fautes ou des ambiguïtés. Pour cela, nous utilisons la pi-logique pour
la spécification des différentes propriétés.
L'exemple que nous présentons dans cette section a pour but d'illustrer la pertinence de notre
approche. C'est un exemple significatif qui est trés librement adapté de Rabhi et al. [ 153].
Un client demande à un agent de la banque de vendre une quantité d'actions d'une société. La
soumission de cet ordre à la plateforme de négociation, pourrait avoir un impact sur le prix du
marché pour les actions de la société. L'agent doit décider par lui-même de la façon de répartir
cet ordre en parts plus petites et du moment opportun pour placer ces ordres sur le marché.
Les services financiers spécialisés utilisés sont exposés en tant que Services Web.
Un client passe un ordre de vente d'une quantité d'actions en communiquant avec un service
de courtage (le courtier). Celui-ci invoque d'autres services composites pour vérifier la
faisabilité de l'opération et pour l'exécuter. Le scénario de cette étude de cas est décrit comme
suit :
- Le Client contacte le service composite de courtage avec l'intention de vendre les actions.
- Le Courtier appelle le service d'Analyse avec les paramétres de la requête.
- La tendance du marché est calculée et un plan de vente est généré et retourné au Client par
le service d'Analyse, pour confirmation.
- Le Client vérifie le plan et l'approuve ou le rejette.
66
- En cas d'approbation, le service de Courtage soumet la commande au service de Change,

selon le plan de vente établi. Chaque commande qui est placée auprés du service de Change
génére un accusé de réception qui est renvoyé au Client.
- Le service de Surveillance surveille chaque commande et les opérations réalisées afin de
détecter d'éventuelles actions illégales telles que les délits d'initiés.
Réactivité (responsiveness) : La propriété indiquant que chaque fois que le Client envoie un
ordre de vente, il obtiendra un plan de vente aprés un temps fini, et chaque fois qu'un client
accepte un plan de vente, et l'ordre est approuvé par le service de Surveillance, il recevra un
accusé de réception, est une propriété de réactivité. Cette propriété peut être formalisée par la
formule suivante :
Disponibilité : La propriété indiquant que dans chaque état le service de Courtage (Broker)
peut accepter une demande est une propriété de disponibilité. Cela peut être exprimé par la
formule suivante :
Fiabilité : La propriété indiquant que la réception d'une livraison est garantie à chaque fois
qu'un plan de vente a été envoyé. Ce qui donne la formule suivante :
Equité : La propriété indiquant que si un client envoie un nombre infini d'ordres de vente, il
recevra un nombre infini de plans de vente et des reçus, est une propriété d'équité. Cela peut
être exprimé par la formule suivante :
Vivacité : Une propriété de vivacité correspond à vérifier qu'à tout instant le système conserve
la possibilité de reproduire toutes les actions. Un exemple d'une propriété de vivacité
pertinente au cas d'utilisation du marché d'action est le suivant : le systéme exécutera l'action
de vérification de l'ordre d'achat chaque fois qu'il aura exécuté l'action d’approbation. Cela
peut être exprimé par la formule suivante :
67
9. Conclusion
Nous avons présenté dans ce chapitre les différentes transformations à savoir, AUML/BPEL
et puis BPEL/pi-calcul qui sont à la base de notre protocole d’interaction pour l’intégration et
l’interopérabilité des processus.
Nous avons utilisé le formalisme graphique AUML accompagné d’une spécification textuelle
BPEL4WS pour la modélisation des actions de communication entre les différents partenaires
de l’interaction.
Ensuite, nous avons proposé une sémantique opérationnelle de notre modèle. Cette
sémantique est basée sur des règles de transformation garantissant le respect de la cohérence
du système. Le modèle formel que nous avons retenu pour la représentation du comportement
observable des processus métiers est le pi-calcul.
Pour la vérification des propriétés du protocole d’interaction mis en œuvre, nous avons utilisé
la logique temporelle la pi-logique.
Dans le chapitre suivant nous allons mettre en exergue notre architecture qui permet
l’intégration et l’interopérabilité en exploitant les protocoles d’interaction définis selon
l’approche présentée précédemment. Cette architecture est basée agent, ce qui permet à
l’ensemble des agents d’exploiter ce PI pour assurer une intégration fiable. Tous les
composants de cette architecture seront détaillés et mis en exergue.
68
Un couplage agent et web service pour
l’intégration et l’interopérabilité des
applications basées sur les E-Services
4
1. Introduction
Certaines propriétés fondamentales telles que le passage à l’échelle (la scalabilité),

l'interopérabilité et la réutilisabilité sont nécessaires dans les systèmes d’infomation.
Cependant, ces propriétés sont difficiles à mettre en œuvre lorsque nous utilisons des
architectures traditionnelles. Pour satisfaire ces propriétés, le paradigme agent a reçu
beaucoup d'intérêt. Sans doute, les Systèmes Multi-Agents (SMA) semblent être les candidats
les plus prometteurs quant au développement des systèmes.
Par conséquent, le développement de systèmes à base de services est actuellement en plein
essor. D'autre part, chaque SI pourrait être vu comme un réseau d’entités autonomes, où
chaque SI s’oriente vers la réalisation d’une tâche précise. Cette tâche est généralement
associée à un objectif que nous qualifions de but global. Cet aspect est au cœur de notre
problématique, puisque nous nous intéressons aux systèmes distribués, autonomes et
hétérogènes, dans lesquels chaque sous-système est dédié à la réalisation d’un fragment d’une
tâche globale et possède ses propres objectifs. Dans ce cas, un problème crucial concerne la
capacité de deux systèmes (ou plus) à coopérer et à échanger de l’information afin d’atteindre
un but global. Nous parlons alors d’interopérabilité entre les systèmes pour la réalisation du
but.
Cependant, notre objectif est de concevoir et implémenter une architecture basée agent pour
l’intégration des processus métiers au moment de l’exécution et l’amélioration de la gestion et
le suivi de l’intégration. Cette architecture inclut une bibliothèque de protocoles d’interaction
implémentés d’une manière générique, et propose une société d’agents interactifs.
En outre, ce travail montre un cadre architectural cohérent qui permet le développement des e-
services interopérables à mesure où ces systèmes évoluent. Nous considérons deux types
d’exigences : les exigences fonctionnelles et les exigences système.
69
Un couplage agent et web service pour l’intégration et l’interopérabilité des applications basées sur
les E-Services
a) Les exigences fonctionnelles

La fonction clef de notre système doit faciliter le partage de l'information en permettant aux
différents acteurs appartenant à des systèmes disparates l'accès aux données. A cet égard, le
système devrait permettre:
• La disponibilité de l’information à tout moment, à n’importe quelle situation et

n’importe où (commune, laboratoire, etc.).
• La circulation de l’information doit être contrôlée.

b) Les exigences système
D’autres exigences non fonctionnelles sont la clé de voute de tout système distribué et qui
constituent le noyau de notre travail. Les principales exigences système sont :
l’interopérabilité, l’intégration et la réutilisabilité en exploitant notre PI défini dans le chapitre
précédent. Nous allons aborder ces exigences tout au long de ce travail d’une manière
explicite et parfois implicite.
70
les E-Services
2. Motivation
De nombreux chercheurs dans le domaine affirment que les services web seuls sont
considérés comme passifs, tandis que les agents peuvent fournir des alertes et des mises à jour
lorsque de nouvelles informations deviennent disponibles. Malheureusement, ces technologies
ont été à l'origine développées séparément avec différentes normes et caractéristiques. En
conséquence, leur intégration devient importante dans ce contexte.
En effet, notre idée est d'exploiter les capacités proactives d'interaction des agents afin
d'améliorer le comportement des services web dans une architecture coopérative et orientée-
service.
En outre, avec ce paradigme, les composants logiciels où chacun représente un ensemble de
services gérés par un agent qui à son tour va coopérer avec les autres agents pour fournir des
services unifiés. Ceci correspond bien avec la prédiction de Huhns et Singh [80] "Les agents
deviendront une partie essentielle de la plupart des applications web, servant comme une colle
qui permet à un système aussi grand que le web d'être maniable et viable".
Dans notre travail, nous suivons la démarche où les services web sont invoqués séparément
des agents logiciels comme étant des comportements composables. Ainsi, l'autonomie et
l'intention se présentent uniquement au niveau des agents logiciels qui sont représentés
comme des composants dans une architecture logicielle coopérative. En effet, le fait d'utiliser
des services web c'est pour changer le comportement du système sans arrêter son exécution, et
donc éviter de coder manuellement. Ainsi, une certaine malléabilité est créée en donnant la
possibilité aux utilisateurs d'adapter les services selon la tâche à effectuer.
Nous dressons ci-dessous un tableau comparatif de ces deux technologies agent et service
web.
Propriétés/technologies Service web Agent SW + agent

Sémantique - + +
Usage grand échelle + - +
Proactivité - + +
Collaboration - + +
Interopérabilité + - +
Tableau.4.1 – Comparaison entre service web et agent
Cette étude nous montre qu'en combinant ces deux technologies, nous obtenons une synergie
d'intégration qui remédie la faiblesse de chaque technologie tout en renforçant leurs avantages
individuelles.
Nous motivons le développement d’une architecture d’intégration et d’interopérabilité qui
utilise l’approche agent par :
71
les E-Services
– L’approche "systèmes multi-agent répartis" s’adapte bien à la nature du domaine

d’intégration d’applications par coordination des processus (ensemble des processus métiers
autonomes, géographiquement dispersés et voulant coopérer pour réaliser un but commun).
– L’exécution efficace et la supervision des processus métiers répartis exigent des réactions
rapides de la part des organisations membres. Les réseaux sont les médias privilégiés pour la
communication, de ce fait, le besoin que chaque organisation possède un " représentant " dans
le réseau. Cela peut être matérialisé à l’aide de la notion d’agent.
– L’introduction de ce paradigme dans le domaine d’intégration d’applications permet de
bénéficier des solutions apportées par les travaux de recherche dans le domaine de l’IA et de
l’agent. Par exemple, pendant la coordination des processus métiers dans laquelle il est
nécessaire de sélectionner des partenaires et de distribuer des tâches, montre le besoin de
certaines caractéristiques du système telles que le besoin de négociation. Ces points ont été
discutés profondément dans des travaux de recherche portant sur les SMAs.
– Le mécanisme d’adaptabilité des SMAs semble être adéquat pour l’intégration dynamique
dans laquelle, différents niveaux de coordination avec des ensembles différents de partenaires
pourraient être établis dans les différentes phases.
– L’infrastructure SMA est un ensemble de services, de conventions et de connaissances
supportant les interactions sociales complexes des agents. La coordination et la résolution des
problèmes distribués sont des problèmes critiques pour l’intégration et l’interopérabilité
d’applications. Néanmoins, ils peuvent trouver des solutions acceptables dans une approche
multi-agent.
– Une approche multi-agent fournit une bonne solution pour la mise en œuvre du scénario
d’intégration, en tenant compte des questions sensibles qui doivent trouver des solutions
satisfaisantes, à savoir : la coordination des processus métiers, le maintien de l’autonomie et
la confidentialité des données.
3. Aperçu de l’approche proposée

Les solutions que nous exposons dans ce travail exploite le couplage agent-web services en
mettant en exergue la notion de protocole d’interaction (voir figure 4.1).
La collaboration dans les e-services est généralement gérée par des processus métiers. A partir
de la figure 4.1, notre système est composé de deux niveaux : back office et front office.
La première partie de notre architecture doit assurer la collaboration des systèmes
d'information représentant les participants dans le back office. Ces participants offrent des
services gérés par des agents intelligents qui ont besoin de travailler sur la base d'un protocole
d’interaction nommé PIS (Protocole d’Interaction pour le e-Service). Chaque agent gère
plusieurs services Web.
72
les E-Services
Dans notre approche, les différents agents interagissent en envoyant des messages à l'aide d'un
langage de communication d'un niveau élevé (FIPA-ACL). Le PIS sera utilisé par un agent
intermédiaire dit: "Agent de protocole d'interaction" pour se coordonner avec d'autres agents
du système. Ce protocole devrait être publié et partagé par l' « Agent de protocole
d'interaction» pour une éventuelle réutilisation et adopter le processus d'intégration et
d’interopérabilité pour contrôler de manière efficace toutes les étapes de composition et de
surveillance [148].
La deuxième partie de notre architecture est le front-office [146] [148]. Le citoyen peut
directement atteindre le portail de notre système via Internet et peut choisir le service dont il a
besoin. Il activera automatiquement l’agent utilisateur. Le type de service sélectionné lui
permettra d'être connecté directement avec la partie back-office. Eventuellement, l’agent
utilisateur peut coopérer avec les autres agents du back office dans le cas où le service voulu
est de nature complexe.
Nous allons présenter dans les sections suivantes les spécifications des différents composants,
ainsi que les concepts liés à leurs fonctionnements.
73
les E-Services
Figure – 4.1. Architecture du système proposé
74
les E-Services
4. Description des différents composants de notre architecture
Notre architecture est composée de deux niveaux: le front office et le back office. Dans cette
section, nous fournissons la description et le rôle des différents composants de notre
architecture.
4.1. Système front office
Le citoyen peut directement atteindre le portail de notre système via Internet et peut choisir le
service dont il a besoin [148]. Le type de service sélectionné lui permet d'être connecté
directement avec l’hôte qui offre cette aide (à la suite d'un mécanisme bien défini dans notre
approche). Nous devons prendre en considération le protocole HTTP qui est présent dans
notre architecture et dont les avantages restent disponibles. Nous utilisons ce protocole dans
l'échange des différentes pages Web. Compte tenu du fait qu'il est considéré comme une
norme, il facilitera l'installation de l'interopérabilité.
Un agent utilisateur (ci-après: AU) est associé à un citoyen (utilisateur). Il support une
structure de données de stockage de profil PU (profil utilisateur) de l’utilisateur et une autre
structure pour les différents services. L’AU est activé par l’utilisateur quand il veut savoir s'il
existe de nouveaux services intéressants pour lui et, dans le cas affirmative, d'y accéder (voir
figure 4.2).
4.1.1. Composant « Agent utilisateur »
Un agent utilisateur est associé à un citoyen pour accéder au système. Cet agent est composé
de deux structures de données: le profil et la base de données de services et un autre module
d'exécution utilisé pour obtenir le service adéquat.
Figure.4.2 – Structure de l’agent « Agent Utilisateur »
75
les E-Services
4.1.2. Structure « base de données profil »
La base de données de profil stocke toutes les informations sur le profil d'un utilisateur qui
accèdent à notre système. Il se compose du triplet = <Id, Di, Ki> dont:
Id: Identifiant de l’utilisateur;
Di: informations démographiques sur l’utilisateur pour, 1<= i <=n;
Ki: ensemble de mots clés pour, 1<= i <=n. Le Ki est composé de deux parties: <Mci, Coefi>
pour, 1<= i <=n dont:
• Mci : ensemble de mots clés déjà utilisés;
• Coefi: coefficient calculé par la méthode de Jaccard (Coefficient de Jaccard) [147].
Le coefficient de Jaccard (ou indice de Jaccard) est le rapport entre la cardinalité (la taille) de
l'intersection des ensembles considérés et la cardinalité de l'union de ces ensembles, Il permet
d'évaluer la similarité entre les ensembles [147]. Dans notre application il correspond à :
Coefficient de Jaccard = Qi Π Sj / Qi U Sj.
Tel que : Qi : La requête saisie par l’utilisateur.
Sj : Les services disponibles, qui sont récupérés à partir de la base de données Services.
Le coefficient de Jaccard consiste à calculer l’intersection du Qi et Sj puis la diviser par
l’union du Qi et Sj. Le résultat obtenu sera un nombre appartenant à l’intervalle [0,1].
4.1.3. Structure «base de données de services »
L’agent utilisateur exploite également la base de données de services pour stocker et gérer des
informations sur les différents services offerts par les participants. Chaque service est
caractérisé par les informations suivantes:
(i) identifiant du service offert,
(ii) un ensemble de mots clés qui le décrivent,
(iii) un ensemble de contraintes nécessaires à l'accès; chaque contrainte est représentée par un
couple (n, v), où n est le nom de la contrainte, et v est sa valeur (ou un ensemble de valeurs),
qu’il doit prendre en compte pour permettre l’accès au service. En premier lieu, l’agent
utilisateur récupère PUi de la base de données de profil et les stocke dans sa structure de
données de support. Ensuite, il permet à l’utilisateur d'envoyer une requête Qi, constitué d'un
ensemble de mots-clés qui précisent les services qu'ils désirent actuellement.
Après cela, il envoie la paire <Qi, PUi> au composant «Moteur d'exécution», qui est en charge
du traitement de la requête et la construction d'une liste SLi de services répondants peut-être à
la demande de l’utilisateur. Cette liste de services est construite en exploitant le coefficient de
Jaccard tels que :
Coefficient de Jaccard = Qi Π Sj / Qi U Sj .
76
les E-Services
Le composant «moteur d'exécution» (voir figure 4.2) construit cette liste et la propose à
l’utilisateur. Il peut choisir les services les plus pertinents, en fonction de ses besoins.
Sur la base de ses choix, le « moteur d’exécution » convenablement mis à jour PUi. Cette
activité comprend deux étapes, à savoir:
• Insertion / Mise à jour des intérêts. Dans ce cas, l’agent utilisateur examine à la fois Qi
et les caractéristiques des services de SLi choisis par l'utilisateur. Il ajoute dans Ki le
mot clé qui n’est pas déjà présent, et lui associé un degré d'intérêt initial approprié. En
outre, pour chaque mot déjà présent dans Ki, il met à jour convenablement le degré
d'intérêt correspondant.
• Suppression des anciens intérêts. Dans ce cas AUi retire de Ki tous les mots clés qui ne
sont plus intéressants pour les utilisateurs. L'activité de l'élagage permet au AUi de
maintenir le PUi mis à jour et, en même temps, permet d'éviter la croissance excessive
de la taille de PUi
Une fois que le service est sélectionné par l’utilisateur final, il accédera directement au service
qui fournira cette aide où il peut interagir avec d'autres agents du système. Enfin, quand un
utilisateur termine ses activités, l’AU met à jour la base de données de profil utilisateur.
4.2. Système back office
L'architecture que nous avons proposée (voir figure 4.1) est fondée sur un framework qui se
compose de plusieurs agents en interaction et d’une bibliothèque de protocoles PIS [148].
En effet, le framework offre aux agents des composants de base et une structure minimale et
qui interagissent. Ils peuvent être réutilisés par le développeur pour créer ses agents.
Aussi, la bibliothèque qui contient un ensemble de protocoles d’interaction PIS dont les rôles
sont mis en œuvre en tant que composants. Cette bibliothèque est gérée par l’«Agent de
protocole d’interaction ». L’ensemble de ces protocoles sont les différentes stratégies
dont l’agent «Agent de protocole d’interaction » exploite pour atteindre ses objectifs.
Cependant, l’autonomie, la répartition géographique sont les caractéristiques des différents
participants dont l’objectif est de coopérer pour réaliser un but commun ce qui correspond à la
notion d’agent. En effet, nous avons placé un agent intermédiaire entre SMA et sa partie de
l’interaction est exprimé avec le langage BPEL4WS. L’«Agent de protocole d’interaction»
(voir dans la section suivante) permet de gérer l'interaction en interprétant
la description du protocole (voir la définition plus détaillée du protocole d’interactions PIS).
PIS devrait être publié, partagé et réuilisé entre les partenaires.
Le processus d'interaction implique des interventions par les différents participants. Un
contrôleur assurant que ces interventions respectent les règles de l'interaction. La mise en
œuvre des interventions reléve de la responsabilité exclusive des entités participantes.
77
les E-Services
Cependant, il n'est pas nécessaire que le code de synchronisation qui traduit le contrôle est
également divisé entre ces entités.
Pour cela, un type d'agent est défini pour le contrôle et le suivi de l'interaction. L'idée de créer
un agent intermédiaire pour le contrôle et le suivi de l'interaction offre de nombreux
avantages, y compris la facilité de la validation, la réutilisation, le maintient des protocoles
d'interaction et permet de créer des agents légers non congestionnés par des règles
d'interaction.
Dans la section suivante, nous mettons en exergue le rôle et la structure interne des différents
types d'agents présents dans notre architecture (la partie du back-office de la figure 4.1).
4.2.1. Structure et rôle des participants
L’agent participant représente un acteur d’un système qui contribue à la prise en charge des
besoins des différents utilisateurs. Il s’agit de fournir une assistance intelligente aux acteurs
humains. Cet agent coopère avec les autres SMA du système afin d’atteindre ses buts.
L’exemple ci-dessous (voir figure 4.3) représente le profil d’un agent participant (Urologue)
dans une structure XML. Le profil des agents est crucial pour un partenariat spécifique afin
d’atteindre un but commun.
<Act_Profil Nom=’Prof. Talhi’>

<Act_specialite> Urologue </Act_ specialite>
<Competence Comp_id=‘Echographie’>
<Designation> Échographie vésico-prostatique </Designation>
</competence>
<Competence Comp_id=’Endoscopie’>
<Designation> endoscopie diagnostique </Designation>
</competence>
</Act_profil>
Figure.4.3 – Profil d’un agent participant
L’agent participant est composé de plusieurs modules qui seront détaillés dans la suite (voir
figure 4.4) :
• La boite aux lettres. Quand les messages arrivent alors que l'agent est dans un état
d'occupation, le module de communication dépose ces messages dans cette boîte aux
lettres. Cette boite est une file d’attente de type FIFO (First In First Out) utilisée pour
stocker les messages afin de les traiter de façon asynchrone.
• L’interface utilisateur. Elle permet l’interaction entre l’agent participant et l’agent
humain (ce dernier joue le rôle de partenaire ou expert). C’est une interface
d’assistance pour l’agent humain.
78
les E-Services
• Le Module de coordination. Ce module prend en considération l’ensemble du

processus global de la coordination. Il prend comme paramètres d'entrées un ensemble
de buts (les résultats d'interprétation des messages par l'interface utilisateur et le
module de communication) et produit un plan qui satisfait ces buts. Le module de
coordination se compose de sous module de « Planification » pour l’orientation et
l’ordonnancement des tâches locales et un sous module de « négociation » pour
l’allocation des tâches, la résolution de conflits et la convergence vers des accords avec
les partenaires.
• Le module de connaissances individuelles. Un agent doit avoir la capacité de
représenter ses connaissances c’est-à-dire de les mémoriser et de raisonner dessus.
Ainsi, la base de connaissances individuelles représente l’ensemble des informations et
des connaissances nécessaires sur l'agent lui-même: ses capacités et compétences, l’état
et la charge de la tâche actuelle. En conséquence, Chaque agent participant garde toute
information relative à ses interventions, ses activités, etc.
• Le module de connaissances du SI. Il contient les informations concernant les règles
organisationnelles et opérationnelles définies dans un système (par exemple: à quel
agent participant du système il doit remettre les résultats d’analyse). Ce qui permet
d’avoir une interopérabilité organisationnelle entre les différents agents partenaires
impliqués dans le système. Il comprend la liste des tous les agents partenaires. Ce sont
des connaissances qui représentent le savoir-faire sur le SI, pour le bon déroulement du
processus de raisonnement et un comportement cohérent. Par conséquent, cette base de
connaissances permet de mener à bien le processus de coopération et la gestion des
interactions avec les autres agents. Ce module contient aussi des informations sur les
droits et les engagements dans notre système.
• Le module de communication. Ce module gère l’interaction entre un agent et le
monde extérieur tels que les autres agents (accointances). Il contient tous les processus
de prise en charge des messages provenant, soit de l’ « Agent du protocole
d’interaction » ou bien d’un autre agent participant. Ce module est responsable de
toutes les fonctionnalités d’expédition et de réception des messages.
79
les E-Services
Figure.4.4 – Structure de l’agent participant
4.2.2. Structure de «Agent de protocole d’interaction »
Notre approche d'intégration et d’interopérabilité utilise un modèle de coordination basé sur

des agents qui offrent des services. Comme le montre la figure 4.5 l'agent de protocole
d'interaction se compose de cinq modules principaux et d’une table d’historique (définie plus
loin section 6):
- La boite aux lettres : Quand les messages arrivent alors que l'agent est dans un état
d'occupation, le module de communication dépose ces messages dans cette boîte aux
lettres. Cette boite est une file d’attente de type FIFO (First In First Out) utilisée pour
stocker les messages afin de les traiter de façon asynchrone.
- Le module d’analyse : Il représente un canal ou un support des messages entre un agent

et son coordinateur. Ce composant fournit les comportements de base de communication,
qui sont l’acheminement des messages reçus vers les composants qui doivent les traiter, et
l’envoi des messages reçus par les composants vers les agents destinataires. Les messages
sont décrits avec le langage de communication de FIPA-ACL.
- Le module d’interaction : Ce module comme son l’indique assure le traitement des

messages en se basant sur la spécification BPEL4WS des PI et la partie connaissances.
- Le gestionnaire des web services offre les fonctionnalités nécessaires pour la

localisation et l’invocation de services.
- Le module d’information : Le rôle de ce module est de contenir les informations qui

sont nécessaires pour le bon déroulement de l’interaction. Parmi ces informations se
80
les E-Services
trouvent les états courants des tâches en cours d’exécution. Ces informations sont
utiles pour une éventuelle réutilisation du protocole.
Figure.4.5 – Structure de l’agent « Agent de protocole d’interaction »
4.2.3. Bibliothèque des protocoles d’interaction
Une autre composante de notre architecture qui joue un rôle très important est la bibliothèque
des protocoles d’interaction. Cette dernière est gérée par l’ «Agent protocole d’interaction»
qui transmet les rôles aux agents participants.
En effet, les principaux attributs d’un protocole que nous considérons et qui permet
d’introduire quelques aspects de son implémentation sont :
– l’identifiant de l’interaction.
– le nom du rôle et le nom du protocole.
– un ensemble non vide de messages propres au protocole.
– l’état final de l’interaction qui peut avoir la valeur "succès" ou "échec". Cette information
est retournée à l’ «Agent protocole d’interaction» à la fin de l’interaction. Sur la base de cette
information, l’agent peut entreprendre certaines actions, tels que l’enregistrement du résultat
de ses interactions ou la décision de s’engager dans une nouvelle interaction.
Ces informations sont extraites à partir du document BPEL4WS. Pour une éventuelle
réutilisation de ce protocole d’interaction, ces informations sont stockées dans la table
d’historique de l’agent protocole d’interaction.
81
les E-Services
5. Comportement des agents du système

Dans cette partie, nous allons définir les stratégies des rôles endossés par les différents agents
de notre système à partir de la spécification du PI.
De plus, on y décrit les réactions d’un agent à un message donné ainsi que les procédures qui
déterminent ces réactions. Celles-ci peuvent en retour être la génération de nouveaux
messages [148].
Dans cette section, nous décrivons cette spécification, notamment les rôles et comportements
des agents impliqués dans notre protocole, ainsi que la formalisation des résultats attendus en
sortie à l’issue de leur coordination.
5.1. Rôles des agents
Trois principaux rôles interviennent dans le protocole d’interaction que nous avons défini et
que nous voulons concevoir :
1. L’agent utilisateur qui est principalement en charge d’interagir avec l’utilisateur et de
diffuser ses requêtes aux agents participants à l’interaction dans le cas où le service demandé
est complexe.
A la fin de la coordination, il reçoit les réponses des agents et il prend également en charge de
les trier en fonction du profil de l’utilisateur.
2. Les agents participants Dans notre approche, chaque agent participant peut avoir les
compétences pour résoudre une ou plusieurs requêtes. Cependant, ce type d’agents ont pour
rôle de se coordonner afin de répondre aux requêtes de l’ «Agent protocole d’interaction». Le
protocole d’interaction que nous spécifions dans ce chapitre décrit les règles utilisées par les
agents participants pour se coordonner. Aussi, nous précisons les conditions sous lesquelles
ils envoient leurs messages réponses à l’ «Agent protocole d’interaction».
3. L’agent de protocole d’interaction son rôle se résume en l’utilisation des données se
trouvant dans la spécification du protocole d’interaction et de les envoyer aux agents
participants à l’interaction.
Notre protocole d’interaction est basé sur l’hypothèse que les agents n’ont aucune
connaissance les uns sur les autres et qu’ils doivent se coordonner en produisant un flux
optimal de messages et en procédant au minimum des traitements nécessaires.
5.2. Comportement des agents
Après avoir défini les différents rôles des agents, nous présentons le comportement du SMA
de notre système qui peut être décrit comme suit :
82
les E-Services
– Le début du processus d’intégration est à la charge de l’ «Agent de protocole

d’interaction » qui exploite le protocole d’interaction pour envoyer une annonce à
l’ensemble des participants. En effet, dans notre approche, l’ « Agent du protocole
d’interaction » mémorise les contraintes relatives à la tâche et encapsule sa description
dans un message, devenant un message initiateur (m0), qu’il diffuse à tous les agents
participants.
– Lorsqu’un agent participant reçoit un message, il le traite selon ses connaissances et
réalise la partie qui lui a été assignée.
– Lorsque les agents ont résolu toutes les requêtes contenant des sous buts. La
composition des résultats individuels aboutit à la réalisation du résultat final qui est le
but global.
– L’ « Agent du protocole d’interaction » assure la coordination au niveau inter-agents
(inter-participants) en respectant les règles d’interaction définies dans la spécification
BPEL4WS. Dans le contexte de ce travail nous n’aborderons pas l’aspect de
coordination locale, et qui peut être différent d’un participant à un autre.
A partir de cette explication, il ressort trois propositions à prendre en considération :

Proposition 1 Lorsqu’un agent participant a fini de résoudre toutes ses requêtes, il les
regroupe dans un message qu’il envoie à l’agent protocole d’interaction.
Proposition 2 Le rôle d’un agent participant se termine dès lors qu’il a résolu toutes ses
requêtes.
Proposition 3 L’ «Agent protocole de l’interaction » termine son rôle dès lors qu’il a
collecté tous les messages réponses des agents participants.
Pour garantir cette dernière propriété, il faut que l’ « Agent protocole d’interaction » sache
à combien de messages réponses il doit s’attendre de la part des agents participants. Cela
est possible à partir du moment où il collecte au moins un message par agent participant.
L’analyse des réponses et la sémantique de l’ACL lui permettent alors de savoir si
d’autres messages sont susceptibles de lui parvenir.
6. Trace des interactions
Les agents dans notre SMA interagissent et se coordonnent en fonction des messages
reçus et de ceux qui se sont précédemment échangés. Pour ce faire, l’ «Agent protocole de
l’interaction » est muni d’une table d’historique.
Une table d’historique regroupe les traces des interactions d’un agent, notamment les
précédents messages qu’il a échangés avec ses accointants, ainsi que le message initiateur
de chacune de ses interactions.
83
les E-Services
Une table d’historique notée ã associée à l’ «Agent de protocole d’interaction » nommé :

a, est un ensemble d’enregistrements, chacun étant dédié à une interaction. Dans ce
contexte, ce que nous appelons interaction c’est l’ensemble de messages échangés pour la
satisfaction d’un ensemble de besoins donnés, suivant le protocole d’interaction.
Une interaction est une séquence de messages échangés entre plusieurs agents, conforme
à un protocole d’interaction. Un enregistrement d’une interaction est défini par :
r = (id;R;m0;M;U) tel que :
– id est l’identifiant de l’enregistrement (ou de l’interaction).
– R est le nom du rôle du protocole
– m0 est le message initiateur de l’interaction.
– M est l’ensemble de messages échangés, i.e. envoyés et reçus, durant l’interaction.
–U est l’ensemble de réponses finales, construites par l’agent, devant être envoyées à
l’agent protocole d’interaction, tel que U={f1, f2,..}. Chaque réponse finale fj= {k1j,..,Knj}
contient une résolution pour chacune des requêtes de l’utilisateur.
Exemple
Supposons que les agents a, b et c soient impliqués dans l’interaction suivante, où le
patron de chacun des messages est {sender, receiver, conv-id, reply-with, in-reply-to, req-
id, content} (le contenu des messages est ici représenté de manière informelle) :
– m0 = {a,b, j81,q20,null, [1],“Enregistre Desperate Housewives”}
– m1 = {b, c, j81, q21, q20, [1], “Quelle est son heure de diffusion ?”}
– m2 = {c, b, j81, q22, q21, [1], “Ce programme est diffusé à 20h50”}
– m3 = {b, a, j81, q23, q22, [1], “Enregistrement effectué”}
Par conséquent, si nous considérons l’agent participant b, celui-ci aura dans sa table
d’historique l’enregistrement :
r = <j81, R1, m0, M= {m0,m1,m2,m3},U ={“Enregistrement effectué”} >.
En effet, si le l’ « Agent de protocole d’interaction » envoie un message initiateur, il crée
un nouvel enregistrement et y mémorise le message.
Dans notre SMA, lorsque l’ « Agent de protocole d’interaction » construit une réponse à
un message reçu, il consulte sa table d’historique afin de répondre en fonction des
précédentes séquences de messages échangés, des agents impliqués et du but de
l’interaction, c’est-à-dire, la satisfaction des besoins de l’utilisateur contenus dans le
message initiateur m0. Par ailleurs, il envoie un message réponse à l’agent participant
lorsqu’il aura résolu la requête de l’utilisateur.
7. Modes de communication
Au sein d'un système multi-agents, les agents doivent pouvoir interagir entre eux pour
atteindre leurs objectifs. Ces interactions sont l'essence même d'un système multi-agents et
84
les E-Services
portent sur les mécanismes leur permettant d'interagir et sur les différentes formes
d'interactions. Celles-ci peuvent se définir en relation avec trois composantes des agents :
7.1. Communication inter-agents dans notre système
La réussite de l’e-service passe également par une communication efficace tout au long de
son déroulement. Les agents doivent communiquer entre eux, aussi bien qu’avec les
services de la plate-forme ou de l’environnement. Plusieurs mécanismes de
communication sont possibles : échange et envoi de messages, invocation des méthodes
ou bien l’utilisation d’un blackboard. Le mode de communication que nous avons adopté
est celui par envoi de messages. En effet, analyser des données, identifier des
informations, maintenir à jour des connaissances, communiquer les synthèses, les
recommandations et les prises de décision des agents hétérogènes par leur fonction et par
leur domaine d’activités, travailler en coopération, nécessite un mécanisme de
communication sans faille.
Notre choix de sélection du langage de communication est basé sur celui qui favorise le
plus l’interopérabilité. L’ambitieux est de définir un langage de communication pour faire
interopérer des agents pour coopérer. En plus, celui qui supporte l’aspect conversationnel
qui convient parfaitement à notre système. En conséquent, des langages de
communication inter-agents standardisés devront être fournis.
Dans notre approche, nous proposons le langage ACL pour formuler les messages
échangés entre les différents agents de notre système. L’enjeu principal de FIPA est la
standardisation dans un but d’interopérabilité les systèmes à base d’agents logiciels
hétérogènes. Parmi ces standards de communication, à l’occurrence le langage ACL FIPA
[32], devenu le standard incontournable pour l’interaction des agents et plus riche
sémantiquement que son rival KQML [149]. Dans notre système l’intérêt principal de la
standardisation est de faire interopérer la société d’agents distincts dans notre architecture,
d’où la motivation de notre choix pour le langage ACL FIPA.
Dans le langage FIPA-ACL, aucun langage spécifique de description des contenus des
messages n’est imposé. Plusieurs langages peuvent être utilisés pour la description du
contenu des messages échangés tels que :
• Le langage KIF (Knowledge Interchange Format) ;
• Le langage sémantique (SL) ;
• Prologue ;
• Le langage XML (Extensible Markup Language)
85
les E-Services
Le langage XML sera employé pour la description, la spécification et l'interprétation du

contenu des messages (CONTENT) échangés entre les différents agents. Donc, les messages
échangés entre les agents sont décrits dans FIPA-ACL/XML. La figure 4.6 représente la
structure d’un message XML dans le langage FIPA-ACL.
(inform
:sender Agent participant 1
:receiver Agent participant 2
:language XML
:content (<rapport>
<examen clinique>
<poids> 65kg </poids>
<tension > 15-9 </ tension >
<fievre> 37 </fievre>
</examen clinique>
<conclusion>
<efr> EFR normales </efr>
<ecg> ECG normal </ecg>
</conclusion> </rapport>))
Figure.4.6 – Structure d’un message XML dans FIPA-ACL
L’utilisation de XML pour le contenu des communications entre agents permet la présentation
des messages entre agents par un navigateur WEB et facilite l’intégration avec les
applications basées WEB existantes. De plus, l’utilisation de XML comme un format
d’échange de données garantit l’homogénéité des agents. En effet, XML permet aux agents
participants de transmettre des informations structurées à l’intérieur, entre et à l’extérieur du
système.
7.2. Les services
Les services représentent les fonctions et les activités, que notre système offre. Chaque
service est invoqué localement ou à distance. Un service demandé peut faire appel (utiliser) à
d’autres services afin de répondre aux besoins des agents participants demandeurs de ce
service. Les services sont invoqués moyennant leur interface WSDL. Les traitements des
requêtes de l’utilisateur, ainsi que le traitement des messages, se situent au niveau des agents,
où s’effectuent le raisonnement et la construction des messages réponses. Ainsi, l’interaction
des services est entièrement régie par le protocole d’interaction que nous avons spécifié.
Toutefois, sur le web, ces messages sont encapsulés dans des messages SOAP et envoyés afin
d’invoquer les services via leur interface WSDL. En effet, les messages SOAP sont contenus
dans des enveloppes et comprennent une en tête, décrite dans la balise <Header>, et un corps
de message, décrit dans une balise <body> que nous avons déjà vu au niveau du chapitre 1
section 2 .
86
les E-Services
A priori tous les services sont indépendants. Les avantages que nous avons pu tirer par
l’utilisation de ces services sont :
• Une meilleure prise de décision

• Les utilisateurs ne sont plus obligés de se connecter à des systèmes différents pour
chercher des informations et des données. Maintenant ils sont orientés (vers l’ « Agent
protocole de l’interaction» ou l’agent utilisateur) pour s’informer sur un service.
• Les possibilités d'évolution (l’ajout d’un nouveau service)
• La réutilisation des services
• L’utilisation des standards pour augmenter l’interopérabilité
D’autres avantages sont présents d’un point de vue de collaboration :
• Créer un partenariat continu entre les différents systèmes

• Etendre les services aux organismes externes.
Prenons l’exemple d’un patient admis dans un hôpital. En effet, avant que le processus de
prise en charge soit déclenché, il s’agit de vérifier la validité de l’assurance du malade
(l’assuré). L’infirmière assistée par un agent participant (demandeur de service) recherche les
informations nécessaires sur l’assurance du malade. Ainsi, l’agent demandeur (infirmière)
demande le service de vérification auprès de l’assurance assistée par un autre agent participant
(fournisseur de service).
Dans notre système, un service offert à un agent participant, peut en réalité être le résultat
d’une collaboration issue d’une multitude de fournisseurs (exemple des résultats d’analyses
peuvent être les fruits de la collaboration de plusieurs laboratoires). Le but est d’exposer des
services dans tel environnement, indépendamment des plateformes logicielles et matérielles.
Ce qui rend les SI hétérogènes et distants interopérables, pour rapprochement des partenaires
(agents utilisateurs). A titre d’exemple, la terminologie qui constitue le service le plus
demandé sur le web. De plus, des statistiques qui sont mises à jour continuellement par le
système d’information. La communication Agent-service Web est accomplie par des
messages SOAP.
8. Avantages de l’architecture proposée
Le développement des SMA pour l’intégration d’applications nécessite une bonne maîtrise
des protocoles d’interaction et de tous les détails de leur utilisation. De ce fait,
l’implémentation des protocoles d’interaction est complexe, de même pour l’implémentation
des agents qui les utilisent.
87
les E-Services
Pour pallier ces problèmes, nous avons développé dans ce chapitre, une architecture basée-
agent permettant l’intégration d’applications.
Hormis cet avantage crucial, notre architecture offre plusieurs autres aspects positifs. C’est
ainsi qu’elle est :
– flexible: car elle est facilement adaptable à d’autres applications grâce au concept du PI (il
suffit de changer le fichier BPEL4WS qui encapsule le PI).
– interopérable: puisqu’elle supporte plusieurs modes de communication telles que la
communication inter-agent et la communication agent-service Web.
– intégrable: puisque elle permet d’intégrer plusieurs processus métiers grâce au PI (agent du
protocole d’interaction).
9. Conclusion
Dans ce chapitre, nous avons présenté une architecture basée sur le concept d’agent et de
protocole d’interaction. Ce framework est divisé en deux couches : front et back office.
Dans une première partie, nous avons présenté un système multi-agents orienté services pour
fournir un bon service aux utilisateurs à travers un portail du e-services. Le système proposé
fournit aux utilisateurs un accès personnalisé et adapté aux besoins, car il tient compte de leur
profil.
La deuxième partie, repose sur deux éléments clés, à savoir un cadre modulaire pour les
agents interagissant et une bibliothèque de protocoles réutilisables PIS.
Notre architecture possède des caractéristiques qui favorisent les mécanismes de
communication et de coordination telles que la communication inter-agent et la
communication agent et services Web.
Néanmoins, une étude de cas est nécessaire pour l’évaluation des différentes idées dans un
environnement réel. Cette étude de cas va permettre d’aborder la phase d’implémentation que
nous pensons qu’à ce stade d’étude, nous ne pouvons parler d’implémentation que de point de
vue simulation.
88
Quelques aspects d’implémentation
de l’étude de cas :
« E-Assurance »
5
1. Introduction
Après avoir présenté notre contribution dans les deux chapitres précédents, à savoir le
protocole d’interaction et une architecture basée-agent, nous aborderons dans ce chapitre les
concepts techniques liés à l’implantation de notre solution proposée.
Nous décrivons l’utilisation d’un point de vue pratique notre solution proposée au problème
d’intégration et d’interopérabilité. Une étude de cas nous permet de mieux comprendre et
mieux cerner tous les éléments intervenant dans cette architecture. Cette étude de cas s’inscrit
essentiellement dans le cadre du Gouvernement Electronique (pour e-gouvernement) que nous
avons décrit au niveau du chapitre 2 section 9.
Dans un premier temps, nous nous basons sur cette étude pour mettre en exergue les différents
aspects liés au PI. Ensuite, nous présentons l’implémentation des éléments de base de notre
architecture à savoir le back et le front office.
Une brève présentation de la plate-forme JADE qui est capable d’implanter ce travail est mise
en évidence. Nous motivons ce choix dans ce qui suit avec la présentation des outils
nécessaires pour le développement.
2. Etude de cas
Dans cette section, nous présentons l’énoncé de notre étude de cas et le développement de
l’application « E-Assurance » liée au domaine e-gouvernement présenté au niveau du chapitre
2 section 9.
89
Quelques aspects de l’implémentation de l’étude de cas : « E-Assurance »
2.1. Enoncé
L’utilisation des technologies de l’information et de la communication dans le domaine de

l’administration et des services publics est devenue quasi incontournable. Elle permet, en
effet, un rapprochement entre les citoyens et ces services publics, particulièrement dans celles
qui traitent de la coordination des processus dans les différentes administrations publiques.
Cependant, les applications e-gouvernement sont de nature réparties englobant un grand
nombre d’entités administratives autonomes supportées par une variété de systèmes
d’information hétérogènes.
Nous allons montrer comment notre solution va apporter de l’aide aux citoyens et aux
responsables du guichet unique en exploitant l’architecture d’intégration basée agents que
nous avons exposée (chapitre 3 et 4) sur un environnement opérationnel.
2.2. Développement de l’application « E-Assurance »
Le E-Assurance (pour, Electronique Assurance) est un système de gestion des assurances des
différents malades (assurés) de catégories variées [148].
Cette étude de cas vise à exposer les différents concepts rencontrés dans les chapitres
précédents. Pour cela, un exemple d’un scénario a été proposé et qui sera appliqué dans notre
pays, l’Algérie.
Dans ce dernier, les utilisateurs finaux peuvent être des guichets physiques de l’administration
publique qui aident les citoyens à obtenir des services appropriés ou peuvent également être
des citoyens connectés à internet via leurs postes (accéder au portail gouvernemental, de leur
domicile par exemple).
Comme le montre la figure 5.1, l’architecture E-Assurance est composée de deux parties
importantes de notre système, à savoir : partie front office et back office.
Figure. 5.1 – Fonctionnement de le E-Assurance.
90
Nous donnerons plus d’explication sur les deux parties de notre architecture.
2.2.1. Niveau front office
Cette partie consiste dans le développement d’un portail gouvernemental de type

Gouvernement à Citoyen (G2C) à base de la technologie d’agent.
L’objectif de notre portail est de simplifier la vie du citoyen en lui offrant les différents
services des administrations publiques de manière la plus convenable et la plus transparente,
notamment à travers la mise en ligne de ces derniers, ce qui signifie, rendre l’administration
plus efficace et plus facile d’accès pour l’ensemble des usagers. La partie front office vise à
rendre plus commode, plus conviviale, plus transparente et moins onéreuse, l’interaction entre
le gouvernement et ses citoyens.
Notre portail représente un guichet unique virtuel pour la prestation de services publics à la
population. Il consiste en la diffusion électronique d’informations par le gouvernement aux
citoyens et de la mise en place des services électroniques pour faciliter la communication
directe entre le gouvernement et ses citoyens. Ces derniers peuvent trouver toutes les
informations dont ils ont besoin.
Nous supposons qu’un citoyen se présente au niveau du guichet physique de l’hôpital pour un
service donné consistant au bénéfice d’un service hospitalier IRM (Imagerie par Résonnance
Magnétique). Le responsable du guichet d’accueil saisit le matricule du citoyen pour obtenir
les informations le concernant.
2.2.2. Niveau back office
La partie de back office est composée de trois parties qui inter-réagissent : CH (pour, Centre
Hôpitalier), CNAS (pour, Caisse Nationale d’ASsurance) et ASS.C (pour, l’ASSurance
Complémentaire).
Ce scénario commence au moment où un patient se présente au niveau du guichet unique pour
voir s’il peut bénéficier d’une prestation de service remboursable (dans notre cas, l’IRM).
Cette demande va nécessiter l’envoie d’un message request de la partie CH à la partie CNAS.
La réception du message par la CNAS va générer un traitement de vérification. Ce dernier,
consiste au contrôle des paramètres passés par le message et l’application des différentes
règles internes de la CNAS pour que le patient puisse bénéficier du service demandé. Parmi
les règles internes nous pouvons citer quelques unes :
- Un patient ne peut bénéficier qu’une seule fois du traitement de remboursement dans
une semaine pour la même prestation de service.
- Les prestations seront bloquées par la caisse mutuelle du patient pour non paiement
des cautisations dûes.
91
Dans le cas d’une réponse favorable, la CNAS va construire une liste des prestations
remboursables et envoie un autre message à la partie ASS.C pour vérifier si ce patient peut
également bénéficier d’un remboursement auprès de la mutuelle.
Par la suite, l’ASS.C essaye de calculer le taux de remboursement adéquat et de construire à
son tour une liste des prestations remboursables qui peut varier de 0 à 100%. Une fois ce
calcul terminé, un message inform(taux2) est envoyé à la CNAS.
Lorsque la CNAS reçoit la proposition, elle décidera de la réponse finale. Cette dernière est
soit d’envoyer directement le taux précédemment calculer (dans le cas d’un taux2 égale à 0),
soit de calculer le nouveau taux de remboursement et l’envoyer au CH qui terminera le
processus.
Dans notre modélisation, ce cas sera présenté par un ou exclusif (XOR) qui signifie qu’une
seule des alternatives de message peut être envoyée.
Dans ce cas, le CH a deux threads d’interaction qui représentent les messages entrants soit : le
message inform ou propose.
Dans notre contexte, nous supposant que tous les patients sont assurés au moins au niveau de
la CNAS.
Pour mieux illustrer le mécanisme d’interaction entre les trois partenaires, nous allons suivre
notre démarche qui consiste à respecter les règles du PI qui est modélisé en utilisant AUML.
Ce dernier, sera transcrit en BPEL pour être validé à la fin en utilisant le formalisme pi-calcul
(voir figure 5.2).
Figure. 5.2 – Etapes de transformation du protocole d’interaction.
Dans ce qui suit, nous allons mettre en exergue les aspects de développement des différents
mécanismes de notre approche dans le back et front office.
92
3. Application de l’architecture proposée
Après avoir présenté l’énoncé de l’étude de cas et son objectif, nous allons l’appliquer sur
l’architecture proposée dans le chapitre précédent (4).
Notre validation doit porter, tantôt sur le fonctionnement du protocole d’interaction nommé
PEG (Protocole pour le E-Gouvernement) dans le back office, tantôt sur la communication
dans le front office.
Pour cela, nous allons d’abord définir deux classes pour la réalisation de l’interaction et de
l’interopérabilité PEG. Pour ce faire nous définirons les outils technologiques utilisés.
3.1. Back office
Cette partie a pour but d’appliquer, sur le scénario définit précédemment par le schéma de la
figure 4.1 notre démarche méthodologique.
Selon notre approche nous allons d’abord modéliser notre protocole d’interaction PEG en
AUML en utilisant le diagramme d’interaction puis de le traduire en BPEL (voir figure 3.1).
Un diagramme d’interaction peut être vu comme une séquence autorisée de messages entre
agents et un ensemble de contraintes sur le contenu de ces messages [36]. Dans notre cas, ce
diagramme permet de modéliser les interactions entre les différents processus du système.
Dans cette section, nous allons expliquer les étapes de transformation de notre PI.
3.1.1. Spécification informelle : AUML vers BPEL
La figure 5.3 montre un diagramme d’interaction AUML d’une partie de notre exemple. Nous
rappelons que le niveau d’abstraction choisi se restreint aux actions de communication
observables entre les différents processus métiers (voir figure 5.3).
Nous allons mettre en exergue la traduction du diagramme d’interaction vers le code

BPEL4WS en se basant sur les règles de passage déjà établi au niveau du chapitre 3 section 6.
93
AUML BPEL4WS
Règles de
transformation
Figure. 5.3– Etape de transformation de AUML vers BPEL4WS.
Ceci nous permettra de présenter le mécanisme général d’interaction entre les processus
métiers.
Définition des partenaires
En AUML, les protocoles d’interaction sont présentés en général par des rôles. La partie
"Rôle" du diagramme d’interaction est explicitement représentée par la section < partners > de
BPEL4WS. Un partenaire est un processus (et/ou) un service Web évoluant dans une
interaction. En effet, dans notre exemple, nous distinguons trois partenaires (voir figure 5.4):
le CH, CNAS et ASS.C. Le code en BPEL suivant montre la définition des partenaires de
l’interaction.
94
<partners>
<partner name="CH"/>
<partner name="CNAS"/>
<partner name="ASS.C"/>
</partners>
Figure. 5.4 – Génération des partenaires en BPEL4WS.
Définition de l’interaction
Cette partie est consacrée à la définition de l’interaction entre les différents partenaires. Nous
considérons seulement les actions de communication observables.
En effet, cette étape consiste à définir l’ensemble des messages échangés durant l’interaction
ainsi que l’association de chaque message d’un partenaire à son partenaire cible.
Par conséquent, nous exploitons la partie <variable> de BPEL4WS pour définir tous les
messages échangés dans le diagramme d’interaction AUML.
Ensuite, la description du processus abstrait de l’interaction, est décrite dans le langage de
description comportementale BPEL4WS en appliquant les règles de correspondances entre
AUML et BPEL4WS définies dans le chapitre 3 section 6. La spécification BPEL4WS
obtenue du comportement observable de l’interaction des trois partenaires, est représentée
dans la figure 5.5.
La combinaison AUML/BPEL4WS permet une description très claire et détaillée du scénario

d’intégration. Néanmoins, bien que très performante, cette combinaison n’offre aucune
structure formelle pour vérifier, valider et évaluer les performances du système avant les
phases d’implémentation.
Par conséquent, il apparaît nécessaire de disposer d’un ensemble d’outils formels capables de
prendre en compte ces aspects de validation. L’approche proposée dans ce travail, est basée
sur l’utilisation du pi-calcul. Ce formalisme offre la possibilité de décrire le système d’une
95
Figure. 5.5 – Génération des variables en BPEL4WS.
façon claire et réaliste. Il est développé pour raisonner sur les systèmes distribués
communicants et spécifier le comportement de processus concurrents, c'est-à-dire des
systèmes dont le nombre de processus ainsi que les liens de communication entre processus
peuvent varier dynamiquement.
3.1.2. Spécification formelle en pi-calcul
Dans cette étude de cas, nous utilisons deux types de message : simple et complexe. Dans le
cas d’un simple message, nous pouvons prendre comme exemple le message suivant:
<CH, CNAS, request, A>, c-à-d, que l’hôpital envoie un message simple à la CNAS en
utilisant la performative « request » et dont le contenu est dans A.
Dans le cas d’un message complexe nous avons : <CNAS, CH, inform, A> XOR <CNAS,
CH, propose, A>. Dans ce cas la CNAS peut envoyer soit le message “inform” ou bien
“propose” au CH grâce à l’opérateur XOR.
En appliquant les règles de passage de BPEL/pi-calcul vues dans la section 7 du chapitre 3,
nous obtenons la formule suivante:
96
La transformation en pi-calcul génère trois processus CNAS, CH et ASS de notre système tel
que:
E-Assurrance = {CNAS, CH, ASS} avec un ensemble fini de variables : {ids, idp, taux1,
taux2, tauxglobal, Error} et un ensemble fini de canaux utilisés soit pour l’envoi, soit pour la
réception : canaux= {inform1, inform2, propose, request1, request2, failure}.
Nous allons essayer de donner des explications sur les formules générées.
Formule 1
Cette formule en pi-calcul contient deux parties: une pour l’envoi et l’autre pour la réception.
L’arrivée d’un citoyen à l’hôpital va initialiser le processus CH qui va créer un nouveau canal
“request1” en utilisant l’opérateur « new » pour envoyer les informations du citoyen ‘’idp’’
(l’identificateur (citoyen) et ‘’ids’’ (identificateur du service désiré)). Toutes ces informations
seront reçues par la CNAS. Au même temps il crée un autre canal « inform » pour informer la
mutuelle que le patient dont l’identifiant est ‘’idp’’ est présent dans l’hôpital.
Deux processus peuvent survenir lors de la réception du message: soit CNAS ou CH.
Formule 2
CNAS(x)=if (ids=”true”) then

(v request2).([x=request2]request2<idp,ids>.ASS)
else (v failure).([x=failure]failure<Error>.CH)
97
Lorsque la CNAS reçoit un identificateur correct du patient (ids), elle crée un nouveau canal
(request2) pour envoyer les informations (idp,ids) à l’assurance. Dans le cas échéant, elle
envoie un message d’erreur sur le canal (failure) pour la CNAS (ce cas ne sera pas traité).
Formule 3
ASS(x)= if (ids=”true”) then (v inform2).([x=inform2]inform2<taux2>.CNAS)

Cette formule traite le cas d’une réception d’un identificateur correct reçu de la CNAS. Par
consequent, l’assurance crée un canal (inform2) qui contient un taux calculé (taux2).
Formule 4
CNAS = inform2(taux2).ASS
If (taux2 =0) then (v inform1).(inform1<taux1>.CH)
Else (v propose).(propose<tauxglobal>.CH)
Le premier cas où la CNAS reçoit le taux calculé par l’ASS.C (taux 2) sur le canal “inform2”.
Il teste le taux calculé par l’ASS.C s’il est égal à 0 (le citoyen ne bénéficiera pas de la
mutuelle). Dans ce cas là, la CNAS crée un nouveau canal “inform1” pour envoyer (taux 1)
pour le CH. Dans le cas inverse, il crée un autre canal “propose” pour transmettre le taux
global (tauxglobal). Dans cette formule nous avons utilisé le ‘’if’’ pour présenter les deux
cas. Si nous reprenons tout le processus de transformation nous obtenons ce qui suit (voir
figure 5.6)
Figure. 5.6 – Exemple explicatif du processus de transformation.
98
Formule 5
CH= inform1(taux1).CNAS 0
+ propose(tauxglobal).CNAS 0
Deux cas se présentent pour la réception par le processus CH. Ce dernier, reçoit le (taux1) de
la CNAS, ou bien il reçoit une proposition (tauxglobal). Dans ce cas le processus CH réalise
soit inform1 soit propose est c’est le rôle de l’opérateur (+) de l’algèbre des processus.
3.1.3. Outil HAL
HAL est un acronyme pour HD-Automata Laboratory [73]. C'est un outil intégré construit
pour la spécification, la vérification et l'analyse des systémes concurrents. La boite à outils
HAL est la composante de JACK qui fournit les moyens de traiter le pi-calcul, en exploitant
les automates HD (history dependent). L'objectif de HAL est de vérifier les propriétés des
systémes mobiles spécifiés en pi-calcul.
HAL supporte la vérification des formules logiques exprimant les propriétés du comportement
des spécifications en pi-calcul. L'environnement JACK fournit un model-checker (ACTL) qui
permet de vérifier les propriétés des spécifications en pi-calcul, aprés traduction des pi-
formules exprimant les propriétés souhaitables en formules ACTL. La complexité de
l'algorithme de model-checking dépend de la construction de l'espace d'état du pi-processus à
vérifier, qui est, dans le pire des cas, exponentiel en fonction de la taille syntaxique du
processus.
3.1.4. Spécification des propriétés du PI
A cette étape du processus, nous allons définir un certain nombre de propriétés

comportementales souhaitables pour notre système. Des exemples de propriétés on été
introduites. Nous en avons retenu quelques unes qui nous paraissent pertinentes pour notre
modèle.
Ces propriétés représentent les conditions de base de la validité des spécifications des
protocoles. Ces propriétés peuvent être résumées comme suit :
Réactivité :
A chaque fois que l’hôpital envoie une requête d’un patient, il obtiendra un taux de
remboursement après un temps fini et à chaque fois que la CNAS envoie une requête à la
mutuelle elle obtient toujours un taux 2 même s’il est égal à 0.
99
En HAL :

Disponibilité
La propriété indiquant que dans chaque état la CNAS peut accepter une demande est une
propriété de disponibilité. Cela peut être exprimé par la formule suivante :
Cette propriété se traduit ainsi dans la syntaxe HAL :
Fiabilité
La propriété indiquant que la réception d’un taux2 de la mutuelle est garantie à chaque qu’une
requête contenant idp et ids du patient est reçu de la part de la CNAS. Cela peut être exprimé
par la formule suivante :
Vivacité
Un exemple d’une propriété de vivacité pertinante au cas d’utilidation de E-Assurance est le

suivant : le système exécutera l’action à chaque fois qu’il aura exécuter l’action
inform1(taux1) ou propose(tauxglobal).
Où :
100
Equité
La propriété indiquant que si la CNAS envoie un nombre infini de requêtes (request2), elle
recevra un nombre infini de réponses (inform2). Cela peut être exprimé par la formule
suivante :
Où :
3.2. Le principe du modèle checking
Le model-checking est une technique automatique de vérification formelle d’un système fini.
Il est très utilisé pour étudier les systèmes réactifs, les systèmes critiques, les systèmes temps
réel et les systèmes embarqués complexes.
Le principe de cette technique est le suivant : étant donné un automate à états finis ou bien un
système de transition étiqueté et une propriété désirée, formalisée dans une logique
temporelle, l’algorithme explore l’ensemble des états de cet automate afin de vérifier que la
propriété désirée est bien satisfaite (figure 5.7).
Si ce n’est pas le cas, la séquence de transitions d’état menant à la violation du système est
générée en guise de contre-exemple, ce qui montre que le système est incorrect.
L’algorithme permettant de vérifier si un automate ordinaire satisfait la propriété s’appelle un
model-checker.
Ces propriétés sont de plusieurs types : les logiques temporelles peuvent exprimer les notions
d’accessibilité d’un état, de vivacité (le comportement spécifié aura lieu), d’équité (le
comportement spécifié pourra se produire une infinité de fois) et d’autres.
101
Modèle Formel Propriétés formelles

(Système formalisé en pi-calcul
et traduit en système de (Formule de la logique
transitions ou automate à état temporelle)
fini.
Algorithme de
vérification de système
Diagnostic
(réponse oui ou non)
Figure. 5.7 – Le model-checking.

3.3. Déploiement
La plate forme choisie pour le déploiement de notre système doit répondre à nos attentes et
aux caractéristiques des agents de notre architecture. En particulier, les agents doivent pouvoir
communiquer entre eux.
3.3.1 Interopérabilité de plate-formes
Concernant l’implémentation de notre architecture nous proposons un environnement multi-

agents, i.e. un Framework pour l’implémentation de systèmes multi-agents approprié aux
normes standards, particulièrement pour permettre l’interopérabilité entre agents, ce qui
permettra d’aboutir à un système répondant aux normes courantes. En particulier, un outil
plus adapté pour la simulation de grandes quantités d’agents. Par conséquent, ce type de
plateforme nous parait la plus intéressante pour le déploiement de notre système. Aussi, pour
des raisons de portabilité nous optons pour Java puisque c’est un langage interprété.
Plusieurs plates-formes sont fournies comme logiciels libres. Elles ont été utilisées dans le
développement de plusieurs applications. Parmi elles nous pouvons mentionner : JADE,
ZEUS, et MADKIT pour les agents cognitifs, et SWARM pour les agents réactifs. Il faut
noter que cette liste n'est pas unique, et qu'il y a aussi d'autres plates-formes qui ont été
utilisées avec beaucoup de succès pour bâtir diverses applications.
102
L’environnement JADE [150] a été développé conformément aux standards et spécifications

de FIPA, ce qui rend cet environnement intéressant dans notre travail.
3.3.2. Utilisation de la plate-forme JADE pour le développement de l’architecture proposée
JADE (Java Agent DEvelopement framework) [150 ] est la plate forme qui se rapproche le plus
de nos critères. C’est une plate-forme de création d’agents qui prend en compte les spécifications
de FIPA permettant l’interopérabilité des systèmes multi-agents. Les agents communiquent à
travers des messages représentés en FIPA-ACL. Le concept d’agent est vu par JADE comme un
processus autonome et indépendant qui a une identité, qui requiert la communication
(collaboration, coopération et autre…) avec les autres agents dans le but de remplir ses rôles. Le
but est de simplifier le développement des systèmes multi-agents en conformité avec la norme
FIPA pour réaliser des systèmes multi-agents interopérables.
De point de vue de mise en œuvre, nous avons utilisé une plate-forme basée-agent pour
implémenter les différents agents et concepts. Le choix d’une telle plate-forme est basé sur
plusieurs critères comme :
9 La nature de la plate-forme. Elle peut être soit libre, soit propriétaire. Á la différence
d’une plate-forme propriétaire, celle qui est libre est plus désirée car elle permet aux
utilisateurs d’accéder à plusieurs codes sources;
9 La nature des agents. La plate-forme permet de développer un agent pouvant être soit
réactif, soit cognitif;
9 La richesse de la plate-forme, plus la plate-forme est riche en documentation, en
fonctionnalités et en bibliothèques, plus elle est accessible;
9 La sécurité de la plate-forme, doit offrir des mécanismes de sécurité permettant sa
bonne utilisation;
9 Une bibliothèque de protocoles. Ceux-ci sont compatibles aux standards FIPA et prêts
à être employés pour régir l’interaction inter-agent.
9 Le langage de programmation utilisé par la plate-forme. Un langage qui a fait ses
preuves est mieux qu’un langage inexpérimenté.
Sur la base de ces critères nous avons opté pour la plate-forme JADE qui nous a semblé
correspondre aux critères précédents et qui vont permettre d’implémenter les différents types
d’agents de notre architecture et de simuler l’interaction entre l’agent « Agent protocole
d’interaction » et les agents « Agent administration publique » (les agents participants) durant
la phase d’intégration.
103
3.3.3. Simulation d’interaction entre agents de l’administration publique et l’agent du

protocole d’interaction
Nous allons maintenant simuler l’interaction entre l’agent protocole d’interaction et les agents
des administrations publiques. L’interaction est basée sur l’envoi de messages ACL entre les
agents.
La configuration suivante permet de simuler le lancement de l’environnement JADE sur
plusieurs infrastructures indépendantes.
Lancement de l’environnement graphique de JADE :
C:\jade>java jade.Boot –gui
Cette interface comporte initialement, un container (Main-Container) incluant trois agents
spécifiques (conforme aux spécifications FIPA) :
- Agent Management System (AMS) : C’est un agent permettant aux usagers de contrôler et
de surveiller les agents de la plate-forme. Seulement un AMS existera dans une plate-forme
simple.
- Directory Facilitator (DF) : Agent fournisseur de service de page jaune défini par défaut
dans la plate-forme JADE.
- Agent Communication Channel (ACC) : C’est un composant logiciel contrôlant tous les
échanges de messages dans la plate-forme, ainsi que les messages des plates-formes
éloignées.
Dans cet exemple de code, nous avons défini deux classes publiques : la CNAS et l’ASSC.
Elles sont des extensions de la classe de base de Jade « Agent » et nous avons défini un
nouveau comportement en utilisant l’instruction « addBehavior » (voir figure 5.9).
Le morceau de code (spécification partielle) de la figure 5.8 montre l’implémentation du
module de communication de l’agent « Agent de l’administration publique ». Ce module est
présenté dans notre architecture et est dérivée de la classe CyclicBehaviour de la plate-forme
Jade, elle s’exécutera donc continuellement. Une fois qu’un message est arrivé, le module de
communication interprète les informations obtenues. Ensuite, elle déclenche le module de
coordination et retourne à l’état initial (attendre les messages).
104
import java.util.*;
import jade.core.*;
import jade.core.behaviour.*;
import jade.lang.acl.ACLMessage.*;
class Communication extends CyclicBehaviour
{
public Communication (Agent a)
{super(a);}
Vector goals = new Vector();
public void action( ) {
// attendre un message
ACLMessage received =
myAgent.receive( );
if(ACLMessage == null) {block();}
else {
// message d’interpretation
…………………………
// Start PlanRetrieval Behaviour
addBehaviour(new PlanRetrieval(this,goals));
}}}
Figure. 5.8 – Spécification partielle du module communication.
public class CNAS extends Agent {

protected void setup() {
addBehaviour(new SimpleBehaviour(this)
{
// Traitement ...
}
}
public class ASSC extends
Agent {
class recevoir extends
SimpleBehaviour {
//Traitement ...
}
public recevoir(Agent a)
{
super(a);
}
protected void setup( ) {
recevoir mybehaviour = new recevoir(this);
addBehaviour(mybehaviour); }}
Figure. 5.9 – Extension de la classe « Agent » (CNAS et ASSC).
105
Nous pouvons bénéficier de quelques outils graphiques qu’offre la plateforme JADE,

permettant une meilleure gestion de la communication. Il s’agit de l’agent «Sniffer» (figure
5.10). Il permet de suivre les communications dans la plateforme et donne une interface
graphique pour afficher les échanges des messages entre les différents groupes d’agents.
Nous allons utiliser l’agent sniffer qui a pour rôle de représenter les messages échangés entre
l’agent protocole d’interaction et les différents agents des administrations publiques.
Figure. 5.10 – Interface de l’agent Sniffer.

Le module d’interaction de l’agent « Agent protocole d’interaction » est dérivé de la classe
SimpleBehaviour. Ce module prend comme paramètres d’entrée une spécification BPEL4WS
et construit le protocole d’interaction adéquat. Dans ce contexte, un protocole d’interaction est
un comportement de type FSMBehaviour. Un comportement de type FSMBehaviour est un
comportement composé (CompositeBehaviour) qui exécute ses sous-comportements selon
une machine à états finie définie par l’utilisateur. Chaque sous-comportement représente
l’activité à être exécuté dans un état du comportement FSMBehaviour et l’utilisateur peut
définir les transitions entre ces états. En effet, chaque sous-comportement est dédié à une
interaction qui représente l’ensemble des messages échangés pour la satisfaction d’un
ensemble de besoins donnés.
L’interface qui s’affichera au responsable du poste est la suivante :
106
Figure.5.11 – Interface de la CNAS.

3.2.4. Communication entre agents
Les agents ont besoin de communiquer pour pouvoir interagir et échanger de l’information.
Ils peuvent interagir soit en accomplissant des actions linguistiques (en communiquant entre
eux), soit en accomplissant des actions non-linguistiques, qui modifient leur environnement.
Dans notre architecture en communiquant, les agents peuvent échanger des informations et
coordonner leurs activités. Dans les SMA, deux stratégies principales ont été utilisées pour
supporter la communication entre agents : les agents peuvent échanger des messages
directement, ou ils peuvent accéder à une base de données partagée (appelée tableau noir ou
“blackboard“) dans laquelle les informations sont postées. Les communications sont à la base
des interactions et de l’organisation sociale d’un SMA [151].
Il existe plusieurs langages de communication, qui se basent sur des actes avec des locutions
comme « demander » ou « commander ». Le plus connu parmi ces langages est le KQML, «
Knowledge Query Manipulation Language », et FIPA-ACL. Ces deux langages de
communication entre agents, ont émergé des efforts de standardisation de la communauté des
systèmes multi-agents.
Notre choix de sélection du langage de communication est basé sur celui qui favorise le plus
l’interopérabilité. Notre préoccupation est de définir un langage de communication pour faire
interopérer des agents, de décrire les actions que peut accomplir chaque agent, et de
comprendre la sémantique de chaque tâche à accomplir.
Dans notre travail, le langage XML qui a été présenté dans le chapitre 2 section 3 de ce
manuscrit pour assurer l’interopérabilité est utilisé pour la description, la spécification et
l’interprétation du contenu des messages (Content) échangés entre les différents agents.
107
Donc, les messages échangés entre les agents sont décrits dans FIPA-ACL et XML.
3.4. Front office
À partir de son espace personnel, le citoyen peut lancer une recherche de services. Nous avons
utilisé le coefficient de Jaccard pour obtenir les services demandés par le citoyen. Ce dernier,
permet de calculer la similarité entre le service demandé par le citoyen et les services offerts
par notre portail. La fonctionnalité qui réalise ce calcul est la plus importante dans l’agent
utilisateur de notre architecture côté front office.
Voici un exemple qui montre comment calculer ce coefficient.
Nous supposons que le service demandé est : « IRM ».
Nous récupérons les services offerts par notre portail, puis nous invoquerons la méthode
«similarity» qui permet de calculer le coefficient de Jaccard comme le montre le code suivant:
for (Enumeration e = Description.keys() ; e.hasMoreElements() ; ) {

String element = e.nextElement().toString();
System.out.println(element);
String serv[] = element.split(" ");
double cj = similarity(reqT, serv); }
Figure. 5.12 – Invocation de la méthode ‘’similarity’’.

Dans cette partie de code, nous faisons appel à la méthode similarity qui a comme
paramètres : la requête de l’utilisateur et le service offert par le portail gouvernemental.
Le code de la méthode similarity(x,y ) est spécifié comme suit:
private static double similarity(List<String> x, List<String> y) {

if( x.isEmpty() || y.isEmpty() ) {
return 0.0;
}
Set<String> unionXY = new HashSet<String>(x);
unionXY.addAll(y);
for (Iterator iter = unionXY.iterator(); iter.hasNext(); ) {
System.out.println(iter.next());
}
Set<String> intersectionXY = new HashSet<String>(x);
intersectionXY.retainAll(y);
(Iterator iter = intersectionXY.iterator(); iter.hasNext(); ) {
System.out.println(iter.next());
}
return (double) intersectionXY.size() / (double) unionXY.size();}
Figure. 5.13 – Code de la fonction ‘’similarity’’.
108
Cette fonction consiste à réaliser l’intersection sur l’union après avoir récupéré les valeurs de
X et de Y pour calculer leurs taille à la fin.
Dans cet exemple, le coefficient de Jaccard vaut 1 selon les mots clés utilisés et les services
offerts par le gouvernement. Nous affichons au citoyen le service demandé à savoir : «IRM».
3.5. Discussion
Notre étude de cas est liée au domaine d’application comportant des services de le E-
gouvernement. Ce derniers est un environnement ouvert et dynamique et qui opére sur des
sources d’information hétérogènes.
L’implémentation du système est basée sur la plate-forme JADE qui permet de simplifier le
développement des systèmes multi-agents tout en fournissant un ensemble complet de
services et d’agents conformes aux spécifications FIPA. Aussi, nous avons utilisé les
standards FIPA-ACL et XML pour représenter les informations échangées entre les agents
durant l’interaction et favoriser ainsi l’interopérabilité.
Notre architecture offre plusieurs autres intérêts. En effet, elle est :
–Portable : car elle est programmée en Java ;
–Générique: facilement adaptable à d’autres applications grâce au concept du protocole
d’interaction (il suffit de changer le fichier BPEL4WS qui encapsule le protocole
d’interaction). Dans notre étude de cas nous avons choisi le domaine d’aplication e-
gouvernement. Notre architecture peut être appliquée dans un autre domaine.
–Interopérable: puisqu’elle support plusieurs modes de communication tels que la
communication inter-agent et la communication agent-service Web.
Notre proposition de créer un agent intermédiaire pour exécuter les protocoles d’interaction
offre beaucoup d’avantages, notamment, la réutilisation et la facilité de la maintenance des
protocoles d’interaction. En plus, elle évite d’encombrer les agents participants avec les règles
d’interaction.
Bien que notre architecture offre plusieurs avantages, elle peut connaître des améliorations.
Cette étude de cas ne démontre qu’une catégorie partielle d’applications qui peuvent être
développée au-dessus de notre approche. C’est ainsi que nous prévoyons d’inclure deux
nouveaux mécanismes : un mécanisme pour la gestion des nouveaux agents entrant dans le
système et un autre mécanisme pour détecter les incohérences d’un protocole d’interaction
pendant son exécution.
109
4. Conclusion
Dans ce chapitre nous avons présenté une étude de cas qui a illustré le système E-Assurance.
Nous avons essayé de rapprocher l’aspect de mise en œuvre de notre architecture proposée. Ainsi,
nous avons décrit le processus de formalisation et de vérification du PI. Aussi, nous avons spécifié
notre architecture pour l’intégration et l’interopérabilité d’applications. Cette architecture est
appliquée au domaine du e-gouvernement et plus précisément le E-Assurance. Nous avons utilisé
la plate-forme JADE pour le développement de cette architecture, ce qui nous a permis d’effectuer
des simulations concernant les interactions inter-agents. En effet, nous avons pu montrer l’aspect
interopérabilité et intégration. L’utilisation d’XML pour la description du contenu des messages
permet de les visualiser dans un navigateur WEB, puisque JADE fournit des outils en extension
permettant l’exécution des agents dans un navigateur.
110
CONCLUSION GENERALE
Conclusion et bilan du travail
Le spectre de l’intégration et de l'interopérabilité est très large et la problématique est très

complexe. Elle est encore d'autant plus compliquée dans les e-services qui chevauchent
plusieurs champs d'application tels que le génie logiciel, la modélisation des entreprises, les
systèmes Workflows et la composition des Web services.
Cette complexité est dûe à plusieurs facteurs. Parmi lesquels, nous citons principalement le
degré d’ouverture des processus métiers qui sont gérés par les partenaires coopératifs.
Un autre type de complexité concerne l'intégration de plusieurs aspects qui sont par nature liés
à tout processus métier. Nous citons ceux qui sont considérés comme des aspects de base qui
sont de type informationnel, fonctionnel, comportemental, organisationnel et enfin de
ressources.
Notre travail de thèse s'inscrit dans cette problématique et avait pour objectif principal de
résoudre les problèmes d’intégration et d’interopérabilité des services.
Ainsi, nous avons utilisé le formalisme graphique AUML [36] accompagné d’une
spécification textuelle BPEL4WS [4] pour la modélisation des actions de communication
entre les différents partenaires de l’interaction.
Pour cela, nous avons utilisé le langage BPEL4WS qui est un langage de composition de
services Web permettant de définir des processus métiers et de décrire les interactions entres
les services. BPEL4WS décrit ces interactions à travers un plan en spécifiant les flots de
contrôle entre les services partenaires et les dépendances des données entre plusieurs
processus métiers.
Par la suite, pour permettre la vérification formelle de spécifications écrites en WS-BPEL,

nous avons défini une transformation qui traduit des processus WS-BPEL vers le pi-calcul
fournissant ainsi une sémantique formelle pour WS-BPEL, garantissant ainsi le respect de la
cohérence du système.
Le modèle formel retenu pour la représentation du comportement observable des processus
métiers est le pi-calcul de l’algére des processus [72].
Enfin, la vérification de protocole d’interaction est mise en œuvre. Pour cela, nous avons
utilisé la logique temporelle pi-logique. Finalement, nous avons traduit les propriétés
exprimées dans la pi-logique en une syntaxe adaptée à l'outil HAL qui est le model-checker
pour corriger et valider le modéle.
111
CONCLUSION GENERALE

Les phases précédentes ont permis de concevoir un protocole formalisé et validé. En se

fondant sur ce protocole d’interaction, nous avons défini une architecture système permettant
l’intégration et l’interopérabilité des processus métiers.
Cette architecture repose sur deux éléments clés : un framework modulaire d’agents
interactifs et une bibliothèque de composants réutilisables.
Le framework d’agents fournit les composants de base et une structure minimale d’agents
interactifs que le développeur réutilisera pour déployer ses agents.
La bibliothèque contient un ensemble de protocoles d’interaction et elle est exploitée par un
agent intermédiaire baptisé "Agent de protocole d’interaction".
Nous nous penchons sur les systèmes multi-agents dont l’interaction est directe, régie par les
protocoles d’interaction.
Enfin, la derniére partie de ce manuscrit a été consacrée à l’implémentation. Notre domaine
d’application choisi est le e-gouvernement (E-Assurance) qui présente les caracéristiques
recherchées à savoir : ouverture, hétérogéniété, distribution.
Pour implémenter cette architecture de le E-assurance, nous nous sommes basés sur des
standards. Pour cela, nous avons utilisé les technologies FIPA-ACL et XML pour représenter
les informations échangées entre les agents durant l’interaction. L’architecture proposée a été
implantée en utilisant la plateforme Jade. Cette plate-forme permet de simplifier le
développement des systèmes multi-agents tout en fournissant un ensemble complet de
services et d’agents conformes aux spécifications FIPA.
Perspectives envisagées
Bien que le travail présenté a fourni quelques solutions pour l’établissent des mécanismes
d’intégration et d’interopérabilité, plusieurs aspects sont soumis à de nouvelles améliorations
et à des approfondissements. Certains de ces aspects ont fait l’objet d’étude dans des travaux
et des thèses au sein de notre équipe du laboratoire (LIRE) de l’université de Constantine 2.
D'autres travaux futurs peuvent s'orienter dans de nombreuses et différentes directions tant
pour des aspects pratiques que théoriques :
- Le temps joue un rôle fondamental dans les architectures orientées services et de ce

fait il mérite une attention toute particuliére. Les propriétés temporelles affectent le
comportement de la composition des services et changent les propriétés qualitative du
systéme. Cela est particuliérement important dans le contexte d'activités de longue
durée dans lesquelles la capacité de fournir la fonctionnalité requise est étroitement
dépendante du temps et du type de relations qui relient les activités entre elles. Ainsi
l'élèment wait de WS-BPEL peut-être modélisé. Nous pouvons en faire de même pour
le pi-calcul qui peut de ce fait être étendu pour intégrer une dimension temporelle.
112

CONCLUSION GENERALE

- Si un agent requiert des fonctionnalités, et qu’aucun protocole d’interaction n’est apte

à les fournir, il devrait être possible de combiner des protocoles existants afin de
répondre aux besoins de cet agent. A ce stade, il est nécessaire de connaître la
structure interne de chaque protocole pour pouvoir le composer correctement. Une
étape de vérification est alors nécessaire pour s’assurer que l’intégration des
protocoles est correcte.
- Nous avons l'intention de proposer une ontologie des protocoles d'interaction pour
définir les concepts communs à ces PI, leurs relations et axiomes exprimant des
contraintes sur ces concepts. Cette ontologie fournit une sémantique claire.
- Nous avons souligné que le système proposé est une tentative d'application de la
technologie des agents intelligents dans le contexte de l'e-gouvernement. En ce qui
concerne cela, nous avons montré que de nombreuses caractéristiques typiques des
agents peuvent jouer un rôle clé dans ce contexte.
Aussi, notre prochain travail consistera à compléter le portail public de l'e-
gouvernement qui fournit des services aux citoyens répartis partout dans le monde.
Nous allons également intégrer une ontologie pour capturer plus de concepts sur les
domaines et événements de la vie de e-gouvernement. En outre, un événement de la
vie et des descriptions des services seront intégrés dans le portail.
113

REFERENCES BIBLIOGRAPHIQUES
[1] W3C (2004), “Web Services Architecture”. http://www.w3.org/TR/wsarch/.
[2] W3C (2000), “Simple Object Access Protocol (SOAP)”. http://www.w3.org/TR/soap/.
[3]W3C(2004), “WebService Definition Language (WSDL 1.1)”.
http://www.w3.org/TR/wsdl.
[4] OASIS (2007), “Web Services Business Process Execution Language Version 2.0”.
http://bpel.xml.org/.
[5] W3C (2001), “XML Schema”. http://www.w3.org/XML/Schema.
[6] OASIS (2004), “Universal Description, Discovery, and Integration (UDDI)”.
http://uddi.xml.org/.
[7] Peltz, C. (2003), “Web Services Orchestration and Choreography. Computer Journal”,
Vol. 36(No. 10), IEEE Computer Society Press, pp: 46–52.
[8] Rojas, H.-D. (2006), “Orchestration à Haut Niveau et BPEL », Master’s thesis, Université
Joseph Fourier de Grenoble.
[9]W3C(2004),”OWL-S: Semantic Markup for Web Services”.
http://www.w3.org/Submission/OWL-S/.
[10]CMS-WG(2006),”WSMO:WebServiceModeling Ontology.
http://www.wsmo.org/TR/d2/v1.3/.
[11]W3C (2005), ‘’Web Services Choreography Description Language Version 1.0’’.
http://www.w3.org/TR/ws-cdl-10/.
[12] WMC-WS (2008), “Process Definition Interface - XML Process Definition Language”.
http://www.wfmc.org/xpdl.html.
[13] OMG (2010), “Business Process Model and Notation (BPMN) Version 2.0”.
http://www.omg.org/spec/BPMN/2.0.
[14]Shapiro, R. (2001), “A Comparison of XPDL, BPML and BPEL4WS”. Technical report,
Cape Visions.
[15]Kazhamiakin, R.(2007), “Formal Analysis of Web Service Compositions”. PhD thesis,
Universita degli Studi di Trento.
[16] Mendling, J. (2006), “Business Process Execution Language for Web Service (BPEL)”.
In Aktuelles Schlagwort, EMISA Forum, volume 26, pp: 5–8.
[17] W3C (1999), “XML Path Language (XPath) Version 1.0”. http://www.w3.org/TR/xpath/.
[18]OASIS-BPEL-TC(2006), “BPEL issues list”. http://www.oasisopen.
org/committees/download.php/20228/WS_- BPEL_issues_list.html.
[19] Pagan, F. G. (1981), “Formal specification of programming languages”. Prentice-Hall.
[20] Berard, B., Bidoit, M., Finkel, A., Laroussinie, F.and Petit, A., Petrucci, L., and
Schnoebelen, P. (2001), “Systems and Software Verification”. Springer- Verlag.
[21]Melliti.T (2004), “Interopéerabilité des services Web complexes. Application aux
systèemes multi-agents’’. PhD thesis, Université Paris IX Dauphine.
[22] Papazoglou.M.P (2001), “Agent-oriented technology in support of ebusiness”. Commun.
ACM, 44(4) pp:71–77.
[23] Khezami, N., Otmane, S., and Mallem, M. (2005), “A new formal model of collaboration
by multi-agent systems”. Proc IEEE KIMAS, Massachusetts, USA, pp: 32-37.
[24] Maamar, Z., Sheng, Q. Z., and Benatallah, B. (2003), “Interleaving web services
composition and execution using software agents and delegation”. AAMAS Workshop.
[25] Ferber, J. (1995), ‘’Les systèmes multi-agents : vers une intelligence collective’’.
InterEditions, Paris.
[26]Edgar, M. (1997). ‘’La méthode 1 : La nature de la nature’’. Éditions du Seuil. 30, 40
114
[27]Weyns, D., Parunak. H, Michel. F, Holvoet. T, et Ferber. J. (2005). ‘’Environments for
multiagent systems : Stateof- the-art and research challenges’’.
[28]Shannon.C.,E., Weaver, C.E. (1949). ‘’The Mathematical Theory of Communication’’.
University of Illinois Press, Urbana, Illinois.
[29] Austin, J. (1962). ‘’How to Do Things with Words ?’’, Clarendon Press, London, 1962.
32
[30] Searle, J. (1969). ‘’Speech Acts : An Essay in the Philosophy of Language’’. Cambridge
University Press, Cambridge.
[31] Philip, R. Cohen et Hector, J. Levesque. (1990). ‘’Intention is choice with commitment’’.
Artif. Intell., Elsevier Science Publishers Ltd. 32, 48, pp :213–261.
[32] FIPA.(2001). “FIPA ACL Message Structure Specification” .FIPA. 11, 32, 86
[33] Koning, J.,L., Pesty.S. (2001). “Modèles de communication’’, Chapitre Systèmes Multi-
agents. Hermes.
[34] Rogier M. van E¼k. (2002). ‘’Semantics of Agent Communication : An Introductio’’.
Proceedings of the UKMAS Workshop on Foundations and Applications of Multi-Agent
Systems, London, UK. Springer-Verlag. 32, pp :152–168.
[35] Randall, D., et Reid, G., S,. (1983). ‘’Negotiation as a Metaphor for Distributed Problem
Solving’’. Artificial Intelligence, pp: 63–109.
[36] Bauer.B., Muller.J., and Odell,J. (2000). ‘’Agent UML : A Formalism for Specifying
Multiagent Software Systems’’. In Agent-Oriented Software Engineering, First International
Workshop, AOSE’00, volume 1957 of LNCS, pp: 91–104.
[37] Borger, E. and Stark, R. (2003). ‘’Abstract State Machines: A Method for High-Level
System Design and Analysis’’. Springer-Verlag.
[38] Farahbod, R. (2004). ‘’Extending and refining an abstract operational semantics of the
web services architecture for the Business Process Execution Language’’. Master’s thesis,
Simon Fraser University, Burnaby, Canada.
[39] Farahbod, R., Glässer, U., and Vajihollahi, M. (2004). ‘’Specification and Validation of
the Business Process Execution Language for Web Services’’. In 11th International
Workshop on Abstract State Machines, volume 3052 of Lecture Notes in Computer Science,
pp: 78-94.
[40] Fahland, D. and Reisig, W. (2005). ‘’ASM-based semantics for BPEL: The negative
Control Flow’’. In 12th International Workshop on Abstract State Machines, pp: 131–151.
[41] Börger, E. and Thalheim, B. (2008). ‘’Modeling Workflows, Interaction Patterns, Web
Services and Business Processes: The ASM-Based Approach.’’ In Abstract State Machines, B
and Z (ABZ 2008), volume 5238 of Lecture Notes in Computer Science.
[42] OMG (2010). ‘’Business Process Model and Notation (BPMN) Version 2.0’’.
http://www.omg.org/spec/BPMN/2.0.
[43] Nakajima, S. (2002). ‘’Model-Checking Verification for Reliable Web Service’’. In
OOPSLA Workshop on Object-Oriented Web Services.
[44]Nakajima, S. (2002). ‘’Verification of Web Service Flows with Model-Checking
Techniques’’. In First International Symposium on Cyber Worlds (CW’02), pp: 378–386.
[45] Holzmann, G. (2004). ‘’The Spin Model Checker: Primer and Reference Manual’’.
Addison-Wesley, Boston, MA, USA.
[46] Nakajima, S. (2005). ‘’Lightweight formal analysis of Web service flows’’. In Progress
in Informatics, pp: 57–76.
[47]Nakajima, S. (2006). ‘’Model-Checking Behavioral Specification of BPEL
Applications’’. Electronic Notes in Theoretical Computer Science, pp: 89–105.
[48] Fu, X., Bultan, T., and Su, J. (2004). ‘’Model Checking XML Manipulating Software’’.
In 2004 ACM SIGSOFT international symposium on Software testing and analysis, pp: 252 –
262.
115
[49] Fu, X. (2004). ‘’Formal Specification and Verification of Asynchronously
Communicating Web Services’’. PhD thesis, University of California, Santa Barbara, CA,
USA.
[50] Betin-Can, A., Bultan, T., and Fu, X. (2005). ‘’Design for Verification for
Asynchronously Communicating Web Services’’. In 14th international conference on World
Wide Web, pp:750–759.
[51] Bultan, T., Fu, X., and Su, J. (2006). ‘’Analyzing Conversations of Web Services’’. In
Internet Computing, IEEE, pp:18 – 25.
[52] Holzmann, G. (2004). ‘’The Spin Model Checker: Primer and Reference Manual’’.
Addison-Wesley, Boston, MA, USA.
[53] Fu, X., Bultan, T., and Su, J. (2004). ‘’WSAT: A Tool for Formal Analysis of Web
Services’’. In 16th International Conference on Computer Aided Verification, volume 3114 of
Lecture Notes in Computer Science, pp:510–514.
[54] Diaz, M. (2003). ‘’Vérification et mise en oeuvre des réseaux de Pétri’’. Lavoisier [55]
Choquet-Geniet, A. and Richard, P. (2006). ‘’Petri nets, An introduction to software
specification: a case study’’. Hermès.
[56] Stahl, C. (2004). ‘’Transformation von BPEL4WS in Petrinetze’’. Master’s thesis,
Humboldt-Universität zu Berlin, Berlin, Germany.
[57] Schmidt, K. and Stahl, C. (2004). ‘’A Petri net semantic for BPEL4WS - validation and
application’’. In Kindler, E., editor, 11th Workshop on Algorithms and Tools for Petri Nets,
pp: 1–6.
[58] Hinz, S. (2005). ‘’Implementierung einer Petrinetz-semantik für BPEL’’. Master’s thesis,
Humboldt-Universität zu Berlin, Berlin, Germany.
[59] Verbeek, H. and van der Aalst,W. (2005). ‘’Analyzing BPEL processes using Petri
nets’’. In 2nd International Workshop on Applications of Petri Nets to Coordination,
Workflow and Business Process Management.
[60] Verbeek, H., Basten, T., and van der Aalst, W. (2001). ‘’DiagnosingWorkflow Processes
usingWoflan’’. The Computer Journal, 44(4). pp: 246–279.
[61] Martens, A., Moser, S., and Funk, A. G. K. (2006). ‘’Analyzing Compatibility of BPEL
Processes’’. In AICT-ICIW ’06. International Conference on Internet and Web Applications
and SerServices/ Advanced International Conference on.
[62] Yi, X. and Kochut, K. J. (2004). ‘’Process composition of web services with complex
conversation protocols: A colored Petri Nets based approach’’. In design, analysis and
simulation of distributed systems conference, pp: 141–148.
[63] Yang, Y., Tan, Q., Xiao, Y., Yu, J., and Liu, F. (2006). ‘’Exploiting Hierarchical CP-
Nets to Increase the Reliability of Web Services Workflow’’. In International Symposium on
Applications on Internet, IEEE Computer Society, pp:116 – 122.
[64] Salaün, G., Bordeaux, L., and Schaerf, M. (2004). ‘’Describing and reasoning on web
services using process algebra’’. In IEEE International Conference on Web Services
(ICWS’04), pp: 43–51.
[65] Bordeaux, L. and Salaün, G. (2005). ‘’Using Process Algebra for Web Services: Early
Results and Perspectives’’. In 5th International Workshop on Technologies for E-Services,
volume 3324 of Lecture Notes in Computer Science, pp: 54–68.
[66] Magee, J. and Kramer, J. (2006). ‘’Concurrency: State Models and Java Programs’’.
Wiley.
[67] Foster, H. (2006). ‘’A Rigorous Approach to Engineering Web Service Compositions’’.
PhD thesis, University Of London.
[68] Rumbaugh, J., Jacobson, I., and Booch, G. (1999). ‘’The Unified Modeling Language
Reference Manual’’. Addison-Wesley.
116
[69] Salaün, G., Ferrara, A., and Chirichiello, A. (2004). ‘’Negotiation Among Web Services
Using LOTOS/ CADP’’. In European Conference on Web Services (ECOWS’04), volume
3250 of Lecture Notes in Computer Science, pp: 198–212.
[70] Milner, R. (1989). ‘’Communication and Concurrency’’. Prentice Hall.
[71] Bolognesi, T. and Brinksma, E. (1987). ‘’Introduction to the ISO Specification Language
LOTOS’’. Computer Networks and ISDN Systems.
[72] Ferrara, A. (2004). ‘’Web Services: A Process Algebra Approach’’. In 2nd ACM
International Conference on Service Oriented Computing, pp : 242–251.
[73] FERRARI, G., GNESI, S., MONTANARI, U. et PISTORE, M. (2003). ‘’A model-
checking verification environment for mobile processes’’. ACM Trans. Softw. Eng.
Methodol., 12.
[74] Kishore, R., Zhang, H., and Ramesh, R. (2006). “Enterprise integration using the agent
paradigm : foundations of multi-agent-based integrative business information systems”.
Decison Support Systems, pp:48–78.
[75] Mazouzi, H., Fallah-Seghrouchni. A., and Haddad,S. (2002). “Open Protocol Design for
Complex Interactions in Multi-Agent Systems”. In AAMAS’ 02 : Proceedings of the first
international joint conference on Autonomous agents and multiagent systems, New York, NY,
USA, ACM, pp:517–526,.
[76] Fallah-Seghrouchni,A., Haddad,S., and Mazouzi, H. (1999).” Protocol Engineering for
Multi-agent Interaction”. In MAAMAW’99 : Proceedings of the 9th European Workshop on
Modelling Autonomous Agents in a Multi- AgentWorld, UK, Springer-Verlag, pp: 89–101.
[77] Marc, F., El Fallah-Seghrouchni, A., Degirmenciyan, I (2003). “Distributed coordination
based on temporal planning for tactical aircraft simulation”. http ://perso.club-
internet.fr/marc.frederic/aamas03.pdf.
[78] Buhler, P.A., and Vidal, J.M.(2005). “Towards adaptive workflow enactment using
multiagent systems”. International Journal On Information Technology and Management,
pp:61–87.
[79] Denning, P.(1992). “ Work in a Closed-Loop Process”. American Scientist.
[80] Singh, M., and Huhns,(1994). “Automated Workflows for Service Provisioning
:Integrating AI and Database Technologies”, IEEE Expert, 9(5).
[81]Chang,M., and Woo,C.(1994). A Speech-Act-Based Negotiation Protocol : Design,
Implementation, and Test Use. ACM Transactions on Information Systems, pp:360–382.
[82] Desai,N., Ashok,U.,Amit,K., and Munindar, P. S.(2006). “OWL-P : A Methodology for
Business Process Development”. In Agent-Oriented Information Systems III, volume 3529,
Springer Heidelberg, pp: 79–94.
[83] Vernadat, F. B.(1996). "Enterprise modelling and integration: Principles and
applications". Chapman & Hall, London.
[84] Weston R. H. (1993). "Steps towards enterprise wide integration: a definition of needs
and first generation open solutions". International Journal of Production Research, 31(9),
pp:2235- 2254.
[85] Williams H., Li F.(1999). “ Interfirm collaboration through interfirm network ”,
Information Systems Journal, pp :103-115.
[86] Boudjlida,N." Intégration et Interopérabilité dans les Environnements logiciels " , Loria,
Université Henri Poincaré Nancy I, Projet Architecture.
http://www.aee.inria.fr/cederom/bilan/docbilan/interop.pdf.
[87] European Interoperability Framework for pan-European e-Government Services. (2004)
“Interoperable Delivery of European e-Government Services to public Administrations”,
Businesses and Citizens (IDABC), November, Luxembourg.
[88] IEEE (Institute of Electrical and Electronics Engineers).(1990). “Standard Computer
Dictionary-A Compilation of IEEE Standard Computer Glossaries”. ISBN: 1559370793.
117
[89] Carney.D et al.(2005). ''Topics in Interoperability : System-of-Systems Evolution,
Integration of Software-Intensive Systems Initiative”, Technical Note, CMU/SEI-2005-002.
[90] The Workflow Mangement Coalition.(1999).”Workflow Management Coalition
Terminology and Glossary”, technical report WfMC-TC-1011.
[91] IDEAS.(2003). “A gap Analysis –Required activities in Research, Technology and
standardisation to close the RTS Gap- Roadmaps and Recommendations on RTS activites”.
[92]ATHENA.(2005). “Report on methodology description and guidelines definition Version
1.0”, ATHENA Integrated Project.
[93] ’’EuropeanInteroperabilityFramework’’.(2004).http://ec.europa.eu/idabc/en/document/34
73
[94]Touzi,J.(2007). ‘’Conception de Système d'Information Collaboratif support de
l'interopérabilité des entreprises’’. Thèse de doctorat, Institut National Polytechnique de
Toulouse.
[95]Ruokolainen,T., et Kutvonen,L.(2006). “Interoperability in Service-Based Communities”,
In BPM 2005 Workshops, LNCS-3812, pp: 317-328.
[96]Hostachy, E.(2000). ‘’Le système d’information doit être centré sur l’EAI’’.
Informatiques Magazine, pp: 40 - 44.
[97]Matjaz B.J.(2002). ‘’EAI and Web Services’’. eAI Journal.
[98] Lee,J., Siau,K., et Hong,S.(2003). “Enterprise integration with erp and eai”. Commun.
ACM, pp : 54-60.
[99] Linthicum, D.S.(2001). “B2B Application Integration: e-Business–Enable Your
Enterprise”. Addison-Wesley.
[100] Pokraev,S.,Quartel,D., Steel, D.S.C.,et Reichert.R,.(2006). “Semantic Service
Modeling: Enabling System Interoperability”. Enterprise Interoperability : New Challenges
and Approaches, Springer Verlag , ISBN-10 : 1846287138.
[101] Zouater,K., Djoudi,A., Boufaida,M.(2008). ‘’Etude du mécanisme d’interopérabilité
dans les systèmes Pair à Pair’’. Mémoire de mater 2 en informatique, pp: 10, Université
Mentouri de Constantine, Département informatique, Algérie.
[102]Ta, T.(2001).’’ Web sémantique et portails’’ ; Thèse de Master, ENST.
[103]Tambouris,E., Gorilas, S.,Kavadias,G., Apostolou,D., Abecker,A.,Stojanovic,L.,et
Mentzas,L.(2004). “Ontology-Enabled E-gov Service Configuration: An Overview of the
OntoGov Project “. Springer Berlin / Heidelberg, ISBN : 978-3-540-22002-2, pp: 122 -127.
[104] Benaben,F., Hanachi,C., Matthieu,L., Couget,P., Chapurlat,V.(2008). “A Metamodel
and its Ontology to Guide Crisis Characterization and its Collaborative Management”. In
Proc. Of the 5th International Conference on Information Systems for Crisis Response and
Management, Washington, DC, USA.
[105]Salzano, G., Bourret, C.(2005). “Identification and Composition of Metadata for
Cooperative Information Systems Illustration on the health information systems”. In procd. Of
FIS2005 Third Conference on the Foundations of Information Science, Paris.
[106] Diego, M., L., Bernd, G.M.E., B.(2009).” A development framework for semantically
interoperable health information systems”. International journal of medical informatics,
pp:83–103.
[107] Zhang, J.K., Xu, W., Ewins, D.(2007). “System Interoperability Study for Healthcare
Information System with Web Services”. Journal of Computer Science, pp: 515-522.
[108]Baldoni,M.,Baroglio,C.,Martelli,A.,Patti,V., et Schifanella,C.(2005). “Verifying the
Conformance of Web Services to Global Interaction Protocols: A First Step “.
[109] Baldoni,M.,Baroglio,C.,Martelli,A.,Patti,V.(2006). ‘’A Priori Conformance Verification
for Guaranteeing Interoperability in Open Environments’’.
[110] Baldoni,M.,Baroglio,C.,Martelli,A.,Patti,V.(2006). “Conformance andInteroperability
in Open Enviroments “.
118
[111] Perrin,O.,Guermouche,N., et Ringeissen,C.(2007). “Timed Specification For Web
Services Compatibility Analysis “.
[112] Montali,M.,Pesic,M., Van Der Aalst,W.P, Chesani,F., Mello,P., et Storari,S.(2009).
“Declarative Specification and Verification of Service Choreographies”. ACM Transactions
on the Web, vol : V.
[113]Chopra,A.K.,et Singh,M.P.(2006). ‘’Producing Compliant Interactions: Conformance,
Coverage, and Interoperability ‘’.
[114]Chopra,A.K.,Baldoni,M.,Baroglio,C.,Desai,N.,Patti,V.,Singh,M.P.(2009).”Choice,
Interoperability, and Conformance in Interaction Protocols and Service Choreographies”, In
Proc. On the Inter Foundation for Autonomous Agents and Multiagent Systems.
[115]Hailstone,R.(2003). “Intégrations strategies : the start of convergence”, IDC.
[116]Yang,X., Yu,G., & Wang,G.(2001). “Efficient mapping integrity constraints from
relational database to XML document”, A. Caplinskas and J. Eder édition, ADBIS,
LNCS2151, Springer Verlag Berlin Heidelberg, pp :338-351.
[117]Haarslev, V.; Möller, R.(2001). ‘’RACER System Description’’. In Proc. of the Int.
Joint Conf. On Automated Reasoning (IJCAR 2001), volume 2083 of Lecture Notes in
Artificial Intelligence, pp : 701–705.
[118]Gruden,A., Strannergrad,P.(2003). “ BPM : the next wave”, eAI Journal, Janvier.
[119] ‘’Spécification du profil UML d’assemblage cible CCM’’.(2002). Projet Rntl accord.
[120]Serain,D.(2001). ‘’Enterprise application intégration’’, 3ème édition, Dunod, Paris.
[121] Vidal,M.,Paul,A., and Verhagen,H.(2003). ‘’Adaptive Workflow = Web Services +
Agents’’. In Proceedings of the International Conference on Web Services : ICWS’03, pp:
131–137.
[122]Alexandre,G.,Wilson,L., Siham,S.(2002). ‘’Intégration des processus métiers dans les
systèmes d’information d’entreprise’’. Technical report, France Telecom.
[123]Morley,C.,Hugues,J., Leblanc,B., and Hugues,O.(2002). ‘’Processus métiers et SI :
Evaluation, modélisation et mise en œuvre’’. Dunod.
[124]Vinoski,S.(1997). ‘’Integrating Diverse Applications Within Distributed Heterogeneous
Environments’’. IEEE Communication magazine.
[125] Herness, E. N., High, R.J., and McGee, J. R.(2004). ‘’WebSphere Application Server :
A foundation for on demand computing’’. IBM Systems Journal, 43(2), pp:213–237.
[126]Morley,C.,Hugues,J.,Leblanc,B., and Hugues,O.(2002). ‘’Processus métiers et SI :
Evaluation, modélisation et mise en œuvre’’. Dunod.
[127]Ribière,G.(1998). ‘’Communication et traitement en mode message avec MQSeries’’.
Technical Report H2-768, Techniques de l’ingénieur.
[128] Alexandre,G.,Wilson,L.,Siham,S.(2002). ‘’Intégration des processus métiers dans les
systèmes d’information d’entreprise’’. Technical report, France Telecom.
[129]Linthicum,D. S.(2004).’’Next Generation Application Integration’’, Addison-Wesley
edition.
[130]Megder,El.,Cherkaoui,C.,Sbihi.B.,Mammass,D.(2005).’’Le E-Gouvernement et la
Modernisation du Secteur Public’’.
[131] Johnston, J.(2001).’’MAKING GOVERNMENT-TO-GOVERNMENT HAPPEN’’,
Unisys, GOVIS.
[132] Pardo, T. A., & Tayi, G. K. (2007). ‘’Interorganizational information integration: A key
enabler for digital government’’. Government Information Quarterly, 24, pp :691−715.
[133] Wang, H., Song, Y., Hamilton, A., & Curwell, S. (2007). ‘’Urban information
integration for advanced e-planning in Europe’’. Government Information Quarterly, 24,
pp :736−754.
119
[134] Eckman, B. A., Bennett, C. A., Kaufman, J. H., & Tenner, J. W. (2007).’’ Varieties of
interoperability in the transformation of the health-care information infrastructure’’. IBM
Systems Journal, 46(1), pp :19−41.
[135] Gouscos, D., Kalikakis, M., Legal, M., & Papadopoulou, S. (2007). ‘’A general model
of performance and quality for one-stop e-government service offerings’’. Government
Information Quarterly, 24, pp :860−885.
[136] Scholl, H. J., & Klischewski, R. (2007).’’ E-Government Integration and
Interoperability:Framing the Research Agenda’’. International Journal of Public
Administration, 30(8), pp :889−920.
[137]Cabinet Office. (2005). ‘’E-Government interoperability framework’’. e-Government
Unit London, UK: Cabinet Office.
[138] State Services Commission. (2007). ‘’New Zealand E-government Interoperability
Framework’’, www.e.govt.nz
[139]Otjacques, B., Hitzelberger, P., & Feltz, F. (2007). ‘’Interoperability of e-government
information systems: Issues of identification and data sharing’’. Journal of Management
Information Systems, 23(4), pp :29−51.
[140]Bekkers, V. (2007). ‘’The governance of back-office integration’’. Public Management
Review, 9(3), pp :377−400.
[141]Santos, E. M. D., & Reinhard, N. (2007). ‘’Setting interoperability standards for
egovernment: An exploratory case study’’. Electronic Government, An International Journal,
4(4), pp :379−394.
[142]Gogan, J. L., Williams, C. B., & Fedorowicz, J. (2007). ‘’RFID and interorganisational
collaboration: Political and administrative challenges, Electronic government’’. An
International Journal, 4(4), pp:423−435.
[143] Venkatraman,M., and Munindar, P.S.(1999). ‘’Verifying compliance with commitment
protocols’’. Int. Journal of Autonomous Agents and Multi-Agent Systems, 2(3) ,pp:217 – 236.
[144] LUCCHI, R. et MAZZARA, M. (2007). ‘’A pi-calculus based semantics for ws-bpel’’.
Journal of Logic and Algebraic Programming.
[145] Tebib,A.,Boufaida,M.(2012). ‘’Using Interaction Protocols to Model E-Business
Applications: A π-calculus based Approach’’, I-ESA’12 (International Conference on
Interoperability For Entreprise Systems And Applications), Valence (Espagne), pp: 341-351,
ISNB: 978-1-4471-2818-2 Springer (Entreprise Interoperability V).
[146] Tebib,A.,Boufaida,M.(2011). ‘’Interoperability of Services in E-Government using
Intelligent Agent and Electronic Government Protocol’’, CIIA’11 (Conférence Internationale
sur l’Informatique et ses Applications), Saîda (Algérie), dblp computer science bibliography,
CEUR Workshop Proceedings, Vol-825, ISSN: 1613-0073.
[147] Wikipedia contributors. (2011). ‘‘Jaccard index’’, Wikipedia, The Free Encyclopedia.
[148] Tebib,A.,Boufaida,M.(2013). ‘’An architecture using formal interaction protocols for
business process integration in e-government’’, Electronic Government, an Int, Inderscience,
E-ISSN : 1740-7508, ISSN print: 1740-7494, accepté.
[149] Finin, T. W.,Fritzson,. and McKay,D.P., and McEntire.R.(1994). ‘’KQML As An Agent
Communication Language’’. In CIKM, pp:456–463.
[150] Huang,C., Trappey,C., Trappey,A. and Ku,C.(2009). ‘’The design of a JADE based
autonomous workflow management system for collaborative SoC design’’. Expert Syst.
Appl., 36(2) ,pp:2659–2669.
[151] Chaib-draa,B.,Jarras,I., et Moulin,B.(2001). ‘’Systèmes multiagents : Principes généraux
et applications’’, dans : J. P. Briot et Y. Demazeau « Agent et systèmes multiagents » chez
Hermès.
120
[152] Demazeau,Y., et Costa, A.R.(1996). ‘’Populations and organizations in open multi-
agent system’’. Proceedings of the 1st National Symposium on Parallel and Distributed AI
(PDAI96).
[153] RABHI, F. A., DABOUS, F. T., YU, H., BENATALLAH, B. et LEE, Y. K. (2004).’’ A
case study in developing web services for capital markets’’. Proc. of the 2004 IEEE
International Conference on e-Technology, e-Commerce and e-Service (EEE 04).
121

Tebib Assia

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tebib Assia

Caricato da

Copyright:

Formati disponibili

République Algérienne Démocratique et Populaire

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

Concepts et Outils pour l’Intégration et

Présentée par : Tebib Assia Dirigée par : Professeur Boufaida Mahmoud

Soutenue à Constantine le : 27/11/2014

Président : ZAROUR Nacereddine Professeur à l’université de Constantine 2

Rapporteur : BOUFAIDA Mahmoud Professeur à l’université de Constantine 2

Examinateurs: FARAH Nadir Professeur à l’université de Annaba

Tout d’abord, je tiens à remercier et exprimer toute ma reconnaissance auprès de mon

Je tiens aussi à remercier Monsieur Mr. ZAROUR Nacereddine, Professeur à l'université

Résumé : L'intégration et l’interopérabilité des processus métiers dans un

Mots-clés Intégration, Interopérabilité, Processus Métier, Protocole

Abstract: Integration and interoperability of business processes in an

Keywords Integration, interoperability, business process, interaction

Chapitre I : Etat de l’art ; Concepts utilisés dans les e-services

Chapitre III : Spécification d’un protocole d’interaction dans les

Chapitre VI : Un couplage agent et web service pour l’intégration

Chapitre V : Quelques aspects d’implémentation de l’étude de

Références bibliographiques……………………………………….……… 114

Figure. 1.2 – Architecture des services Web………………………………………………...9

Figure. 1.3 – Scénario d’utilisation des services Web………………………………………10

Figure .1.4 - Structure des messages SOAP………………………………………………...11

Figure. 1.5 – Chorégraphie de services Web ……………………………………………….12

Figure. 1.6 – Orchestration de services Web …………………………………….…………13

Figure. 1.7 – Structure d’un processus BPEL…………………………………….…………14

Figure. 1.8 – Différents types de branchements proposés par AUML…………….………..20

Figure.2.1 – Intégration par les processus métiers des applications de l’entreprise….……...35

Figure.2.2 – Champs d’intégration d’applications…………………………………….……..46

Figure.3.1 – Etapes de translation du protocole d’interaction………………………..............56

Figure.4.1 – Architecture du système proposé……………………………………………….74

Figure.4.2 – Structure de l’agent « Agent Utilisateur »……………………………..….……75

Figure.4.3 – Profil d’un agent participant………………………………………………..…..78

Figure.4.4 – Structure de l’agent participant……………………………………………...….80

Figure.4.5 – Structure de l’agent « Agent de protocole d’interaction »…………………...…81

Figure. 5.1 – Fonctionnement de le E-Assurance……………………………………….….90

Figure. 5.2 – Etapes de transformation du protocole d’interaction……………………....…92

Figure. 5.3– Etape de transformation de AUML vers BPEL4WS……………………….....94

Figure. 5.4 – Génération des partenaires en BPEL4WS………………………………...….95

Figure. 5.5 – Génération des variables en BPEL4WS…………………………………...…96

Figure. 5.6 – Exemple explicatif du processus de transformation……………………….....98

Figure. 5.7 – Le modèle checking……………………………………………………….....102

Figure. 5.8 – Spécification partielle du module communication…………………………..105

Figure. 5.9 – Extension de la classe « Agent » (CNAS et ASSC).…………………….…..105

Figure. 5.10 – Interface de l’agent Sniffer…………………………………………………106

Figure.5.11 – Interface de la CNAS……………………………………………………......107

Figure. 5.12 – Invocation de la méthode ‘’similarity’’…………………………………..…108

Figure. 5.13 – Code de la fonction ‘’similarity’’……………………………………….......108

LISTE DES TABLEAUX

Tableau.4.1 – Comparaison entre service web et agent…………………………………….71

1. Contexte du travail de recherche

Architectures orientées services SOA

2. Business Process Execution Language for Web Services

Les systèmes multi-agents

Les systèmes multi-agents constituent aujourd’hui une nouvelle technologie pour la

3. Plus connues sous le nom en anglais Foundation of Intelligent Physical Agents

2. Problématique et contribution de la thèse

4. Dans la suite du document, nous utilisons l’acronyme PI pour Protocole d’Interaction

Le modèle formel retenu pour la représentation du comportement observable des processus

Le premier chapitre présente les caractéristiques des architectures orientées services, la

Concepts utilisés dans les e-services

2. Architecture Orientées Services (SOA)

Figure.1.1 – Fonctionnement des services Web

2.1. Architecture de Service Web