Concepts et Outils pour l’Intégration et l ... · Then, the protocol will operate in an architecture based agents which consists of two parts: the front office and the back one

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:

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

Concepts et Outils pour l’Intégration et l’Interopérabilité des Services.

Application dans le cadre du E-Government.

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 إلى إضفاء الطابع

وتم التحقق من بعض الخصائص الديناميكية باستخدام . في حساب التفاضل والتكامل- πالرسمي في نهاية π- ول األ. المكتب األمامي والمكتب الخلفي: قسمين هيكلة قسمة الىبروتوآول يعمل في إنثم، ف. المنطق

الجزء . يسمح للمستخدمين الختيار أفضل خدمة مباشرة من خدمة البوابة اإللكترونية باستخدام وآالء ذآاءزمة نحدد جميع المفاهيم الال. والتحقق من صحتها PIفي SMAالثاني، يستخدم لوصف آيف يستخدملتحديد وإدارة عمليات 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. 3. 4. 5. 6. 7. 8.

Architectures Orientées Services (SOA) ………………………………………... 2.1 Architecture de service Web…………………………………………… 2.2 Standards des services Web …………………………………………… 2.2.1. Web Service Description Language (WSDL)………………… 2.2.2. Simple Object Access Protocol (SOAP)……………………… 2.2.3. Discovery and Integration (UDDI)…………………………… Composition des services Web………………………………………………….. 3.1 Chorégraphie de services Web…………………………………………. 3.2 Orchestration de services Web ………………………………………… 3.3 Langages de description de la composition de services ……………….. 3.4 Business Process Execution Language (BPEL) ……………………….. 3.5 Discussion sur les langages de description de services Web ………….. Systèmes multi-agent et interaction …………………………………………….. 4.1 Concept d’agent………………………………………………………… 4.2 Modes d’interaction…………………………………………………….. 4.3 Langages de communication entre agents………………………………. 4.4 Protocole d’interaction …………………………………………………. Langage semi-formel de modélisation « Agent UML »………………………… Aperçu des outils formels……………………………………………………….. 6.1 Travaux sur l’Abstract State Machines (ASM)………………………… 6.2 Travaux sur les systèmes états-transitions……………………………… 6.3 Travaux sur les réseaux de pétri………………………………………… 6.4 Travaux sur l’algèbre des processus……………………………………. 6.4.1. Utilisation du pi-calcul………………………………………. 6.4.2. Définitions…………………………………………………… 6.5 Logique temporelle pi-logique…………………………………………... 6.6 Synthèse ………………………………………………………………… Quelques travaux reliés aux PI………………………………………………….. Conclusion ……………………………………………………………………….

8 8 10 10 11 11 12 12 13 13 14 15 16 16 17 17 18 20 21 21 21 22 23 24 25 26 27 27 29

Chapitre II: Intégration et interopérabilité des services en ligne 1. Introduction………………………………………………………………………. 31 2. 3. 4. 5. 6. 7. 8. 9. 10

Intégration vs interopérabilité……………………………………………………. 2.1 Concept d’intégration …………………………………………………… 2.2 Concept d’interopérabilité……………………………………………….. Principaux types d’interopérabilité………………………………………………. 3.1 Interopérabilité technique………………………………………………... 3.1.1 XML……………………………………………………………. 3.1.2 EAI……………………………………………………………… 3.2 Interopérabilité sémantique……………………………………………… 3.2.1 Ontologie……………………………………………………….. 3.2.2 Quelques projets sur l’interopérabilité sémantique…………….. 3.3 Interopérabilité organisationnelle………………………………………... 3.4 Discussion………………………………………………………………... Différents aspects de l’interopérabilité…………………………………………... Quelques travaux liés à l’interopérabilité et aux services……………………….. 5.1 Travaux antérieurs………………………………………………………. 5.2 Synthèse…………………………………………………………………. Différents aspects d’intégration………………………………………………….. 6.1 Intégration de données ………………………………………………. 6.2 Intégration des applications …………………………………………. 6.3 Intégration des processus…………………………………………….. Quelques approches pour l’intégration des applications………………………… 7.1. Workflow et serveurs d’application…………………………………. 7.2. Applications basées sur un échange des messages………………….. 7.3 Adaptateurs et connecteurs…………………………………………... 7.4. Synthèse……………………………………………………………... Principaux champs d’intégration des applications………………………………. Exemple de domaine d’application: le E-gouvernement………………………… 9.1. Définitions…………………………………………………………... 9.2. Interopérabilité dans le e-gouvernement……………………………. Conclusion………………………………………………………………………..

32 32 32 33 33 34 34 35 36 36 36 37 38 40 40 41 42 42 42 43 43 43 44 45 46 46 47 47 48 50

Chapitre III : Spécification d’un protocole d’interaction dans les e-services 1. Introduction ……………………………………………………………………... 51 2. 3. 4. 5. 6.

Motivation……………………………………………………………………….. Fondements de notre approche………………………………………………….. Définition du protocole d’interaction……………………………………………. Etapes de transformation du protocole ………………………………………….. Translation du diagramme d’interaction vers la spécification BPEL4WS……... 6.1. Messages échangés …………………………………………………… 6.2. Représentation des messages complexes……………………………… 6.2.1 Activité « switch »……………………………………………. 6.2.2. Activité « if »………………………………………………… 6.2.3. Constructeur « flow »………………………………………...

52 53 54 55 56 59 59 59 60 60

7. 8. 9.

6.3. Services web et élément partenaire…………………………………….. Passage de WS-BPEL vers le pi-calcul…………………………………………. 7.1. Processus nul…………………………………………………………….. 7.2. Réception………………………………………………………………… 7.3. Emission…………………………………………………………………. 7.4. Messages complexes…………………………………………………….. 7.4.1 Condition……………………………………………………….. 7.4.2. SWITCH……………………………………………………….. 7.4.3. Composition parallèle…………………………………………. 7.5. La boucle « while »……………………………………………………... 7.6. Séquence………………………………………………………………… Spécifications des propriétés du PI……………………………………………… Conclusion……………………………………………………………………….

60 61 62 62 62 62 63 63 64 64 65 66 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. 3. 4. 5. 6. 7. 8. 9.

Motivation……………………………………………………………………….. Aperçu de l’approche proposée ………………………………………………… Description des différents composants de notre architecture……………………. 4.1. Système font office……………………………………………………. 4.1.1. Composant « Agent utilisateur »……………………………. 4.1.2. Structure « base de données profil »………………………... 4.1.3. Structure «base de données de services »…………………… 4.2. Système back office…………………………………………………... 4.2.1. Structure et rôle des participants……………………………. 4.2.2. Structure de «Agent de protocole d’interaction»…………… 4.2.3. Bibliothèque des protocoles d’interaction………………….. Comportement des agents ………………………………………………………. 5.1. Rôles des agents………………………………………………………. 5.2. Comportement des agents…………………………………………….. Trace des interactions……………………………………………………………. Modes de communication……………………………………………………….. 7.1. Communication inter-agents dans notre système……………………… 7.2. Les services……………………………………………………………. Avantages de l’architecture proposée…………………………………………… Conclusion……………………………………………………………………….

71 72 75 75 75 76 76 77 78 80 81 82 82 82 83 84 85 86 87 88

Chapitre V : Quelques aspects d’implémentation de l’étude de cas : « E-Assurance » 1. Introduction ……………………………………………………………………... 89 2.

Etude de cas……………………………………………………………………… 2.1. Enoncé ………………………………………………………………… 2.2. Développement de l’application « E-Assurance »……………………..

89 90 90

3. 4.

2.2.1. Niveau front office………………………………………….. 2.2.2. Niveau back office………………………………………….. Application de l’architecture proposée………………………………………….. 3.1. Back office…………………………………………………………….. 3.1.1. Spécification informelle : AUML vers BPEL………………. 3.1.2. Spécification formelle en pi-calcul…………………………. 3.1.3. Outil HAL…………………………………………………... 3.1.4. Spécification des propriétés du PI………………………….. 3.2. Le principe du modèle checking………………………………………... 3.3. Déploiement…………………………………………………………….. 3.3.1 Interopérabilité de plate-formes…………………………….. 3.3.2. Utilisation de la plate-forme JADE pour le développement de l’architecture proposée………………………………….. 3.3.3. Simulation d’interaction entre agents de l’administration publique et l’agent du protocole d’interaction…………….. 3.3.4. Communication entre agents……………………………….. 3.4. Front office…………………………………………………………….. 3.5. Discussion……………………………………………………………... Conclusion……………………………………………………………………….

91 91 93 93 93 96 99 99 101 102 102 103 104 107 108 109 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

1

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

INTRODUCTION GENERALE

2

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


3

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


4

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

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


5

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.


6

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.

7

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.

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

1


8

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.


9

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.


10

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


11

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.


12

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


13

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


14

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


15

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

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


16

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.


17

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


18

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


19

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.


20

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]


21

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.


22

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


23

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


24

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


25

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


26

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


27

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.


28

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.


29

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.


30

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.

31

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.

Intégration et interopérabilité des services en ligne

2


32

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 :

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

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

L’interopérabilité est la capacité de communiquer avec d’autres systèmes et d’accéder à leurs fonctionnalités [83];


33

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

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


34

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.


35

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 «


36

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


37

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


38

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


39

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


40

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)


41

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,


42

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.


43

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


44

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


45

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


46

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


47

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


48

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é


49

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


50

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.

51

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.

Spécification d’un protocole d’interaction

dans les e-services

3

Spécification d’un protocole d’interaction dans les e-services

52

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.


53

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.


54

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)


55

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


56

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


57

M1

M2

M1

M2

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

Role

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

AND-Split

<flow> <reply name = ‘’M1’’> ….. </reply> <reply name = ‘’M2’’> ….. </reply> </flow>

OR-Split

<switch> <case cond1> <reply name = ‘’M1’’> ….. </reply> </case> < case cond2> <reply name = ‘’M2’’> ….. </reply>

P P


58

M1

M2

M

M

M

Tableau.3.1 – Passage du diagramme d’interaction vers BPEL.

<otherwise> …. </otherwise> </switch>

XOR-Split

<if condition = ‘’cond-bool’’> <reply name = ‘’M1’’> …. </reply> <reply name = ‘’M2’’> …. </reply> </if>

Message synchrone

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

Itération

<while condition = ‘’cond-bool’’> <receive name = ‘’M’’ Partner = ‘’P2’’ ….. </while>

Séquence asynchrone

<sequence> <receive name = ‘’M’’ Partner = ‘’P2’’ …. </receive>


59

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


60

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


61

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.


62

<empty/> 0 (processus nil inactif)

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

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.


63

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 :


64

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 :


65

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

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


66

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.


67

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


68

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.

69

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.

Un couplage agent et web service pour l’intégration et l’interopérabilité des

applications basées sur les E-Services

4

Un couplage agent et web service pour l’intégration et l’interopérabilité des applications basées sur les E-Services

70

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.


71

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 :


72

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


73

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.


74

Figu

re –

4.1

. Arc

hite

ctur

e du

syst

ème

prop

osé


75

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 »


76

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 .


77

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.


78

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.


79

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


80

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


81

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.


82

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 :


83

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


84

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


85

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)


86

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 .


87

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.


88

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.

89

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.

Quelques aspects d’implémentation

de l’étude de cas : « E-Assurance »

5

Quelques aspects de l’implémentation de l’étude de cas : « E-Assurance »

90

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.


91

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.


92

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.


93

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.


94

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.

Règles de transformation

AUML BPEL4WS


95

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

<partners> <partner name="CH"/> <partner name="CNAS"/> <partner name="ASS.C"/> </partners>


96

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:


97

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)


98

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.


99

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.


100

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 : Cette propriété se traduit ainsi dans la syntaxe HAL : 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ù : Cette propriété se traduit ainsi dans la syntaxe HAL :


101

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ù : Cette propriété se traduit ainsi dans la syntaxe HAL :

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.


102

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.

Modèle Formel (Système formalisé en pi-calcul et traduit en système de transitions ou automate à état fini.

Propriétés formelles (Formule de la logique temporelle)

Diagnostic (réponse oui ou non)

Algorithme de vérification de système


103

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 :

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;

La nature des agents. La plate-forme permet de développer un agent pouvant être soit réactif, soit cognitif;

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;

La sécurité de la plate-forme, doit offrir des mécanismes de sécurité permettant sa bonne utilisation;

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.

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.


104

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


105

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

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

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)); } } }

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); }}


106

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 :


107

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.


108

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:

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:

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

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); }

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();}


109

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.


110

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.

111

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.

CONCLUSION GENERALE

112

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.

CONCLUSION GENERALE

113

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

114

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

115

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

116

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

117

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

118

[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/3473 [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 “.

119

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

120

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

121

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

Documents

Concepts et Outils pour l’Intégration et l ... · Then, the protocol will operate in an architecture based agents which consists of two parts: the front office and the back one