Collaboration des Processus Métiers dans les Echanges inter-entreprises (B2B) basée sur le Web Service Resource Framework (WSRF) du Grid

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE Institut National de formation en Informatique (I.N.I) Thèse Présentée pour l obtention du diplôme de : Magister Spécialité : Systèmes d Information et des Connaissances SIC Titre de la thèse: Collaboration des Processus Métiers dans les Echanges inter-entreprises (B2B) basée sur le Web Service Resource Framework (WSRF) du Grid Réalisé par : Mlle. KHELIFA Lydia Nadia Soutenance prévue devant le jury composé de : Présidente Mme. Thouraya TEBIBEL Maître de Conférence, INI, Alger Directrice de Mémoire Mme. Habiba DRIAS Professeur, INI, Alger Co-Directeur de Mémoire Mr. Youcef AKLOUF Chargé de Cours, USTHB, Alger Examinateur Mr. Amar BALLA Maître de Conférence, INI, Alger FEVRIER 2008 B.P 68 M Oued-Smar Alger, ALGERIE Tél : 213 (21) 51.63.91 213 (21) 51.60.77 Fax : 213 (21) 51.61.56 Site Web : http://www.ini.dz Email : www.ini.dz/mail

REMERCIEMENTS Je remercie Pr. Habiba DRIAS, pour m avoir permis d effectuer ce travail sans aucune contrainte et m encouragé toujours et poussé à faire le meilleur de moi de même. Je remercie également Dr. Aklouf Youcef pour avoir encadré ce travail. Ses remarques de fonds ainsi que sa lecture attentive et critique de ce rapport a très clairement permis de modifier la version initiale. Je le remercie aussi pour m avoir accordé toutes les facilités pour le bon déroulement de ce travail. Mes remerciements s adressent aussi aux membres du Jury pour m avoir honoré en consentant à juger mon travail. Je remercie mes collègues du CERIST, pour m avoir soutenu et aider dans l élaboration de ce travail. 2

Sommaire Introduction générale... 8 Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce 1. Introduction... 10 2. Les échanges B2B du e-commerce... 10 2.1 L intégration B2B (B2B integration: B2Bi)... 11 2.1.1 Définition de l intégration B2B... 11 2.1.2 Le But de l intégration... 12 2.2 L interaction B2B... 12 2.2.1 Le modèle en couche du B2B... 12 2.2.2 Les technologies de l interaction B2B... 13 2.2.2.1 Echange électronique des données (Electronique Data Interchange: EDI).. 13 2.2.2.2 Workflow... 15 2.2.3 Les standards du B2B... 16 2.2.3.1 ebxml (Electronic Business XML)... 16 2.2.3.2 RosettaNet... 20 3. Conclusion... 21 Chapitre II : La collaboration des Processus Métiers 1. Introduction... 22 2. Définition des Processus Métiers... 22 3. Le cycle de vie d un Processus Métier... 23 4. La gestion des Processus Métier (Business Process Management : BPM)... 24 5. Les standards de modélisation des Processus Métiers... 26 5.1 Business Process Modeling Notation (BPMN)... 26 5.2 Unified Modeling Language (UML)... 26 6. Les concepts de bases pour la description des Processus Métiers... 27 7. Les standards de description des Processus Métiers... 28 7.1 XLANG... 28 7.2 Web Service Flow Language (WSFL)... 29 7.3 Business Process Execution Language For Web Services (BPEL4WS)... 29 7.4 Business Process Modeling Language (BPML)... 30 7.5 Web Service Choreography Interface (WSCI)... 30 7.6 Web Service Choreography Description Language (WS-CDL)... 31 8. La collaboration des Processus Métiers... 32 9. Les solutions de collaboration des Processus Métiers... 33 10. Synthèse des solutions... 43 11. Conclusion... 45 Chapitre III : Les Processus Métiers et les concepts des Grids 1. Introduction... 46 2. Définition du Grid... 46 3. Les concepts du Grid... 47 3.1 L Organisation Virtuelle... 47 3.2 Les Grid Services... 48 3.2.1 Définition des Grid Services... 48 3.2.2 Les principes des Grid Services... 49 3.2.2.1 Les principes de l Open Grid Service Architecture (OGSA)... 50 3.2.2.2 Le WS-Resource Framework (WSRF)... 52 4. Les Solutions combinant les Processus Métiers avec les concepts des Grids... 57 3

4.1 Pourquoi combiner les Processus Métiers avec les concepts des Grids?... 58 4.2 Les solutions combinant les Processus Métiers avec les concepts du Grid... 59 5. Synthèse des solutions... 67 6. Conclusion... 67 Chapitre IV: Collaboration des Processus Métiers basée sur le Web Service Resource Framework (WSRF) 1. Introduction... 69 2. Pourquoi utiliser les concepts du Grid dans la collaboration des Processus Métiers?... 69 3. Approche adoptée... 71 4. Objectifs du modèle proposé... 72 5. Schéma général... 72 5.1 Architecture proposée... 73 5.2 Description de chaque module... 75 5.3 Fonctionnement de l architecture... 81 5.4 Implémentation proposée pour l architecture... 83 6 Conclusion... 84 Conclusion Générale... 85 Bibliographie... 87 Glossaire... 93 Annexes... 95 Annexe A: Les Services Web... 96 Annexe B : Le Grid computing... 102 Annexe C : Open Grid Service Infrastructure (OGSI)... 108 Annexe D : Exemple d un Service Web à état dans le WSRF... 114 4

Table des Figures Figure 1: Example d échange B2B [66]. ------------------------------------------------------------- 11 Figure 2:Intégration métier [46]. ---------------------------------------------------------------------- 11 Figure 3: Un framework pour l'interaction B2B [27]. ---------------------------------------------- 12 Figure 4: Les couches d'interaction B2B [27]. ------------------------------------------------------ 13 Figure 5 : Architecture de l EDI [34] ----------------------------------------------------------------- 15 Figure 6: Architecture ebxml[31]. ------------------------------------------------------------------ 18 Figure 7: Exemple d'un processus métier. ----------------------------------------------------------- 22 Figure 8: Cycle de vie d'un Processus Métier [46]. ------------------------------------------------- 23 Figure 9: Orchestration versus chorégraphie [78]. -------------------------------------------------- 28 Figure 10: Le modèle de médiation [60]. ------------------------------------------------------------ 36 Figure 11: Gestion P2P du processus collaboratif [61]. -------------------------------------------- 38 Figure 12: Architecture du framework du Processus Métier [64]. -------------------------------- 39 Figure 13: Relation entre OGSA, OGSI et WSRF. ------------------------------------------------- 49 Figure 14: Création d'une instance de service [13] ------------------------------------------------- 50 Figure 15: Publication de Grid Services [45] -------------------------------------------------------- 51 Figure 16: Le mécanisme de notification [13] ------------------------------------------------------- 51 Figure 17: Exemple d'un EPR [83]. ------------------------------------------------------------------- 56 Figure 18: Message SOAP avec WS-Addressing [83] --------------------------------------------- 56 Figure 19: Exemple de notification avec WS-Notification [83]. --------------------------------- 57 Figure 20: Les quatre couches du système [75]. ---------------------------------------------------- 60 Figure 21: L'architecture du BPMM [76]. ----------------------------------------------------------- 61 Figure 22: L architecture proposée [77]. ------------------------------------------------------------- 63 Figure 23: Diagramme de séquence du service vendeur. ------------------------------------------ 65 Figure 24 : Diagramme de séquence du marché pour un commerce directe. -------------------- 66 Figure 25: Fondement de l approche. ----------------------------------------------------------------- 70 Figure 26: Relation entre les partenaires dans une OV. -------------------------------------------- 73 Figure 27: Architecture de la collaboration. --------------------------------------------------------- 73 Figure 28: Les Processus Métiers Publics. ----------------------------------------------------------- 74 Figure 29: Correspondance entre composants de l'architecture et les spécifications WSRF. - 76 Figure 30: Encapsulation des Processus Métiers Publics. ----------------------------------------- 77 Figure 31: Invocation d un Processus Métier Public encapsulé. ---------------------------------- 78 Figure 32: Enregistrement des Processus Métiers Publics encapsulés. -------------------------- 79 Figure 33: Synchronisation entre registre privé de l'entreprise et le registre de l'ov. --------- 80 Figure 34:Détails de l architecture proposée. -------------------------------------------------------- 82 Figure 35 : Le fonctionnement des Web Services -------------------------------------------------- 97 Figure 36: Architecture en pile. ----------------------------------------------------------------------- 98 Figure 37 : La structure d une enveloppe SOAP ---------------------------------------------------- 98 Figure 38 : Les couches de l'architecture du Grid [1] -------------------------------------------- 103 Figure 39 : Resolver un GSH [14].------------------------------------------------------------------ 110 Figure 40: L'invocation d'un Web Service Sans Etat. -------------------------------------------- 114 Figure 41: L'invocation d'un web service à état. -------------------------------------------------- 115 Figure 42: L'approche de ressource pour l'état ---------------------------------------------------- 115 Figure 43: WS-Resource. ---------------------------------------------------------------------------- 116 5

Les Tableaux Tableau 1: Exemple d'une architectutre Grid... 105 Tableau 2: Tableau comparatif entre Grid Computing et P2P.... 107 Tableau 3: Le mapping des concepts primaires de l OGSI aux composants du WSRF [16] 112 6

Résumé Les échanges intre-entreprises du e-commerce est un domaine en plein expansion. La collaboration inter entreprise représente un défi auquel les entreprises sont confrontées. Cette collaboration tourne autour des processus métiers. Cependant, avec l émergence de nouvelles spécifications résultant de la convergence des web services et des Grids, à savoir le Web Service Resource Framework (WSRF) ouvrent de nouveaux horizons pour la collaboration des processus métiers. Le WSRF décrit les web services à état. Le WSRF est un ensemble de spécifications pour spécifier une approche orientée WS-Resource pour la modélisation et la gestion de l état dans un contexte web service. Le présent travail, a pour objectif de définir une collaboration qui se base sur le concept des grid à savoir les organisations virtuelles et le WSRF. Les web services à état sont utilisés pour encapsuler les processus métiers publics de chaque participant. En plus des spécifications du WSRF, le WS- Addressing est également utilisé pour l adressage. Mots clés: Collaboration des processus métier, Grid, WSRF. Abstract B2B e-commerce is an emergent area, which the profit of enterprises depend on its performance. The collaboration of Business Process is a challenge that the companies are facing to. However, the emergent specifications resulted form the convergence of web services and grid i-e Web Service Resource Framework (WSRF) open new horizon for the collaboration of business Processes. The WSRF specifies a WS-Resource approach to modeling and managing state in a Web services context. In this thesis, we present our vision of integrating the WSRF, its specifications and the WS-Addressing to the collaboration of Business Processes. The collaboration of Business Process is described through a collaborative Business Process defined by the whole participants. It s composed of the public Business Processes of each participant. The Stateful Web Services is used to encapsulate the private Business Processes. Then, the choreography of the Stateful Web Services defined by WSRF result the collaborative Business Process. The WS-Notification is used to notify about the state changes for following the execution of the other participant s Business Processes. Keywords: Business Process Collaboration, Grid, WSRF. 7

Introduction générale L ère est à la mondialisation de l'ensemble des échanges économiques. Ces échanges concernent les services, les biens et aussi les facteurs de production, devenus plus mobiles. Certains de ces échanges forment des marchés mondiaux. Ainsi, dans un tel environnement qualifié de hautement compétitif, l échange d information et la collaboration efficace deviennent critiques. L essence même de cet échange et de cette collaboration est le Processus Métier. Le Processus Métier appelé également Business Process représente les interactions sous forme d'échanges d'information entre divers acteurs: humains, applications ou services et processus tiers. Dans la réalité, la collaboration entre les différents acteurs, qui définissent ces processus, est souvent difficile. Même si de nombreuses solutions logicielles ont déjà vu le jour, l hétérogénéité des systèmes demeure une contrainte difficile à dépasser. Cette hétérogénéité peut être résolue avec le paradigme service web. Seulement, la collaboration n inclut pas uniquement l hétérogénéité, elle nécessite d autres notions telle que: la persistance de l état contenu dans les processus métiers d une manière générale et du processus métier collaboratif d une manière particulière; la notification lors d un changement d état ; et finalement, la gestion du cycle de vie des processus métiers. Toutefois, l alignement des Services Web avec celles des technologies du Grid qui a donné naissance aux Grid Services ou encore des Services Web à Etat, a ouvert de nouvelles orientations quant à la collaboration des processus métiers. Le Grid Service ou Web Service à Etat représente un concept du Grid qui a pour objectif de réaliser le partage flexible, sûr et coordonné de ressources ainsi que la résolution coopérative de problème au sein d organisations. Le Web Service à Etat est décrit avec des normes issues du Global Grid Forum (GGF) tel que le Web Service Resource Framework (WSRF) combiné à un autre concept des Grids à savoir les organisations virtuelles sont des candidats potentiels pour la définition d une architecture de collaboration de processus métiers. Principalement, après le succès du Grid noté dans le domaine du e-science. L objectif de ce travail, est de présenter une architecture permettant la collaboration des processus métiers en se basant sur les concepts des Grids, notamment les Services Web à Etat décrit avec le Web Service Resource Framework. 8

Organisation du document Le présent document se compose de quatre chapitres. Dans le premier chapitre, nous présentons le domaine de notre présente étude; les échanges B2B du e-commerce et les différentes technologies supportant ces échanges, afin d introduire le concept processus métier qui représente le noyau de ces échanges. Le second chapitre, porte sur la collaboration des processus métiers en décrivant les processus métiers, et les différentes solutions de collaboration qui existent. Le troisième chapitre comprend les différentes solutions comportant la combinaison des processus métiers avec les concepts des Grids. Les concepts du Grid y sont également décrits. Le quatrième chapitre décrit notre contribution qui consiste en la définition de la collaboration des processus métiers sur les concepts du Grid à savoir l organisation virtuelle et les Grid Services. Une conclusion générale ainsi qu un ensemble de perspectives terminent ce mémoire.. 9

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Chapitre I: Les échanges Business-to-Business (B2B) du e- commerce Résumé: Ce premier chapitre décrit le principe des échanges B2B et de ses différents concepts. Nous commencerons par la définition de l intégration et de l interaction. Ensuite, nous décrirons le modèle en couche et les standards de l interaction inter-entreprises (B2B), afin d introduire le concept des processus métiers. 1. Introduction L évolution du web a révolutionné la façon avec laquelle les entreprises interagissent avec leurs partenaires et clients (consommateurs). Cette révolution représente un défi pour l interaction avec les applications hétérogènes internes et externes de l entreprise pour le Business-to-Business (B2B). Ce dernier représente notre domaine d étude. Ainsi, ce chapitre a pour objectif de présenter les concepts du Business-to-Business (B2B) du e-commerce, en présentant en premier l intégration B2B, ensuite l interaction B2B en décrivant son architecture, ses technologies et ses standards. 2. Les échanges B2B du e-commerce Le e-commerce a été définit par le groupe Gartner 1 comme étant un ensemble de produits et de services qui facilitent l échange de produits, de services et d information à travers des réseaux électroniques dans une entreprise, et entre les entreprises et leurs clients. Le e- commerce dans le B2B requiert l intégration des systèmes partenaires. Cette intégration doit supporter l interopérabilité entre ces systèmes partenaires avec lesquels ils doivent travailler. Le Business-to-Business (B2B) [66] représente une des catégories du e-commerce. Il décrit toute activité se déroulant entre les entreprises, les spécialistes et les professionnels. L utilisation de transactions électroniques entre les entreprises permet de baisser le coût des achats, de réduire et d optimiser les inventaires, d accélérer la mise sur le marché de nouveaux produits, de diminuer les dépenses pour la vente et le marketing et d ouvrir de nouveaux marchés. La figure ci-dessous, est un exemple représentant un échange automatique entre deux entreprises dans un cas commercial. Cet échange concerne un ordre d achat (PO) et d une 1 Le group Gartner étant est une firme américaine de consulting et de recherche dans le domaine de la technologie. Ayant environ 10 000 clients, elle mène des recherches, fournit des services de consulting, tient à jour différentes statistiques et maintient un service de nouvelles spécialisées. http://www.gartner.com/ 10

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce réponse d ordre d achat (POA). Une fois l ordre d achat envoyé par l entreprise, un POA est systématiquement renvoyé du vendeur à l acheteur en confirmant ou en rejetant cet ordre [66]. Figure 1: Example d échange B2B [66]. Les concepts de l intégration et de l interaction du B2B sont très importants dans le cadre du e-commerce du B2B. Ces concepts seront détaillés dans les sections suivantes. 2.1 L intégration B2B (B2B integration: B2Bi) Les entreprises se rendent compte de plus en plus qu'elles font partie de réseaux physiques et de réseaux virtuels complexes d'affaires, dans lesquels les entreprises sont liées par le partage d'informations, les transactions interdépendantes et la collaboration des processus affaires. Les entreprises tendent à intégrer leurs activités économiques pour plusieurs raisons, telle que la satisfaction de client, l excellence opérationnelle, l agilité (organisation virtuelle), la sécurité et la qualité du produit [47]. 2.1.1 Définition de l intégration B2B Le concept intégration du B2B est très important dans le cadre du e-commerce. L intégration métier est la création d une coordination plus serrée parmi les activités métiers conduits par différents individus, groupes de travail ou organisations pour qu un processus métier unifié se forme [47]. La figure 2 illustre un exemple d intégration B2B entre deux entreprises et au niveau de l entreprise elle-même [46]. Figure 2:Intégration métier [46]. 11

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce 2.1.2 Le But de l intégration L intégration est la base de la collaboration entre partenaires et la collaboration est le but de l intégration [75]. Le but de l intégration selon [66] est de connecter des entreprises avec leurs partenaires commerciaux, afin de conduire des affaires. Cette connexion s effectue à travers des échanges de données d affaires. 2.2 L interaction B2B L'interaction est définie en tant que l'interopérabilité et l intégration avec des applications internes et externes d'entreprise [73]. L interaction dans le B2B offre un défi unique à cause des problèmes concernant le passage à l échelle, l autonomie et l hétérogénéité. Le e- commerce dans le B2B requiert l intégration et l interopérabilité entre systèmes partenaires avec lesquels ils doivent travailler. L interaction est aussi requise à un haut niveau de connexion tel que les applications front-end 2 avec les applications back-end 3 mais aussi les sources de données, les applications et le workflow [27]. La figure 3 illustre un exemple de framework pour une interaction B2B incluant deux partenaires. Figure 3: Un framework pour l'interaction B2B [27]. 2.2.1 Le modèle en couche du B2B Les applications B2B se réfèrent à l utilisation des systèmes informatiques, à savoir les serveurs web, les services réseaux et les bases de données, pour conduire des affaires tels que l échange de document et l achat de produits. L interaction du e-commerce dans le B2B se déroule à travers trois couches telles que définit par Medjahed et Al dans [27]: la couche communication, la couche contenu et la couche Business Process (processus métier). Ces couches sont représentées dans la figure ci-dessous et décrites en détail dans ce qui suit : 2 Front-end est une application avec laquelle l utilisateur interagit directement (l utilisateur peut être un humain ou un programme). 3 Back-end est une application ou un programme qui sert indirectement dans le support des services front-end. 12

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Figure 4: Les couches d'interaction B2B [27]. La couche communication : Fournit les protocoles qui permettent l échange de message avec certains partenaires distants. Ces derniers peuvent utiliser différents protocoles de communication propriétaires ou standards (HTTP et SOAP). Les protocoles nécessitent l utilisation de passerelle pour traduire les messages entre les protocoles hétérogènes. La couche contenu : Pour une bonne compréhension de l information, cette couche fournit les langages et les modèles pour la décrire et l organiser. Les interactions dans cette couche accomplissent une bonne intégration des formats de données, des modèles de données et des langages. Le contenu des interactions requiert que les systèmes inclus, comprennent la sémantique et les types des documents métiers. La couche Processus Métier : Concerne les interactions conversationnelles entre services. L interaction dans cette couche permet aux partenaires autonomes et hétérogènes de publier leur vocabulaire et leurs capacités. Elle leur permet aussi de s engager dans des interactions pair-a-pair avec n importe quel partenaire. L interopérabilité dans cette couche, est un défi car elle requiert une compréhension de la sémantique des processus métiers des partenaires. 2.2.2 Les technologies de l interaction B2B Dans ce qui suit, nous détaillons certaines technologies qui supporte l interaction B2B dans le e-commerce. 2.2.2.1 Echange électronique des données (Electronique Data Interchange: EDI) L Electronic Data Interchange (EDI) a émergé dans les années 60 lorsque les entreprises ont senti le besoin de partager leurs données d une manière électronique. Il fut le premier standard pour l échange électronique de l information. L EDI a été défini comme le transfert des documents métiers d'application-à-application interorganisationnel (par exemple, ordres d'achat, factures, notices d expédition) entre les ordinateurs sous une forme compacte. Son but primaire est de réduire au minimum le coût, l'effort, et le temps de transfert des documents d'affaires [27]. Les documents EDI sont 13

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce structurés selon une norme (par exemple UN/EDIFACT 4 ) et un format exploitable par machine. L interaction B2B dans une EDI nécessite : A. Des documents métiers. B. Un Réseau à valeur rajoutée (Value Added Network:VAN): Réseau privé utilisé par une entreprise pour établir un lien de données dédié et servant de lien pour le transfert de données de type EDI ou d autres services réseaux entre partenaires métiers. Avec la venue du World Wide Web, les entreprises ont de moins en moins recours au VAN pour l acheminement des données. C. Un translateur. Comme illustré dans la figure 5: Le document est crée par l application (système d achat) de l émetteur, le translateur est utilisé pour décrire la relation entre les éléments d information dans une application et les standards de l EDI et pour convertir le document EDI en un message EDI dans une enveloppe électronique qui contient un identifiant pour le receveur. La transmission de l enveloppe électronique est réalisée par des logiciels de communications. Ces logiciels conservent le numéro de téléphone du partenaire commercial pour dialoguer et échanger les opérations. Le logiciel de communication peut être une application séparée ou une partie du traducteur. Le message EDI sera alors transmis via le VAN. Ce derniers, après lecture de l identifiant se trouvant dans l enveloppe, le place dans la boite électronique du récepteur et l opération inverse est établie, pour interpréter le contenu de l enveloppe. Les standards EDI, fournissent une solution homogène pour l interopérabilité du contenu Ils définissent également, un ensemble de type pour décrire les documents métiers. Cependant, la conduite d une transaction partenaire ayant des documents dont les paramètres ne sont pas inclus dans les documents EDI représente une limite pour l EDI. 4 United Nation/Electronic Data Interchange for Administration, Commerce, and Transport. 14

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Système d achat Système de commande Document au format interne Conversion EDI translateur Document convertit sous format EDI EDI Messaging Document au format Interne Conversion au format interne EDI translateur Document sous format EDI EDI Messaging VAN Figure 5 : Architecture de l EDI [34] 2.2.2.2 Workflow Un Workflow est un flux d'informations au sein d'une organisation, comme par exemple la transmission automatique de documents entre des personnes. On appelle «workflow» la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier. Ce dernier, consiste en une collection d activité relatives aux données et au flux de contrôle. Une activité est réalisée par l exécution d un programme ou encore par l invocation d autres processus métier. Le Workflow est une technologie clé pour l automatisation des processus métiers qui inclut l accès à plusieurs applications. Ce qui rend le workflow une technologie candidate à l intégration, l automatisation et le monitoring des processus [27]. Le workflow [72] selon le WFMC 5 est «l automatisation d un processus métier dans sa globalité ou en partie, durant laquelle les taches sont transmises d un participant à un autre pour agir suivant un ensemble de règles». Cependant, il peut y avoir plusieurs workflows à gérer, de là, la nécessité d un système de gestion des workflows (WFMS 6 ). Ce système définit par le WFMC comme étant «un système qui définit, crée et gère l exécution de workflows à travers l utilisation de logiciels, qui s exécutent sur un ou plusieurs moteurs workflows, ce dernier est capable d interpréter la définition du processus, d interagir avec les participants du workflow, où est requis d invoquer l utilisation des outils et des applications IT». Lotus Note, Ultimus, Action Works Metro, sont des exemples de produits de gestion de workflow. 5 WFMC: Workflow Management Coalition. 6 WFMS: Workflow Management System. 15

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Les systèmes de workflow [51] peuvent être de type collaboratif. Ce dernier est principalement caractérisé par le nombre de participant inclus et les interactions entre eux. Des projets existent qui étendent les technologies workflow tel que CrossFlow [74]. 2.2.3 Les standards du B2B Plusieurs standards ont été apportés pour décrire les interactions B2B tels qu ebxml et RosettaNet qui reste les plus référencés dans la littérature. 2.2.3.1 ebxml (Electronic Business XML) L ebxml [44] est une initiative lancée en novembre 1999 dont l objectif était de définir un cadre de travail global pour le commerce électronique. Cette initiative est issue de l expérience de praticiens de l EDI et des connaissances des différents secteurs industriels où l échange de données électroniques s applique depuis longtemps avec succès. En effet, les promoteurs d ebxml sont UN/CEFACT 7 (qui a utilisé EDI pendant plus de 20 ans) et OASIS 8 (qui a une grande expérience en XML). L ebxml ne s occupe pas de documents échangés lors de transactions commerciales mais de la formalisation du processus métier. Il s agit d une chorégraphie d activités d une entreprise qui inclut une interaction entre participants sous la forme d échange d informations. Les Processus Métiers ebxml sont définis dans la norme ebpss (electronic business Process Specification Schema). Cette définition consiste en une séquence d opérations représentées par des échanges de messages entre parties prenantes au processus. L initiative ebxml a réuni un consensus autour des composants essentiels au commerce électronique qui sont: des services d annuaire, des Services de Messagerie, des protocoles, des contrats de collaboration et un schéma de spécification des processus métiers. Le détail de chacun de ces composants sera présenté dans ce qui suit : Des Services d annuaire (Registry/Repository): Le service d annuaire proposé par ebxml est similaire à UDDI. Le registre ebxml (ebrim : ebxml Registry Information Model) offre une série de services qui favorisent l échange d information entre parties intéressées, de façon à permettre l intégration d un processus d affaires entre ces mêmes parties en fonction des spécifications ebxml. L information ainsi partagée est conservée sous la forme d objets dans un référentiel et gérée par les services du registre ebxml. Un Registre ebxml fournit un ensemble de services destinés à partager l information entre des Partenaires Commerciaux. L accès au Registre ebxml est fourni par des Interfaces (APIs) publiées par les services du Registre. 7 UN/CEFACT: United Nations/Centre for Trade Facilitation and Electronic Business. 8 OASIS: Organization for the Advancement of Structured Information Standards. 16

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Des Services De Messagerie (Messaging service): initialement, le service de messagerie a été construit sur MIME 9. Depuis février 2001, SOAP y a également été intégré. Ce service de messagerie est un standard OASIS (5 septembre 2002). Il est utilisé dans les échanges de messages lors de transactions de commerce électronique et dans les demandes et requêtes au registre. Les Protocoles et Les Contrats de Collaboration: il s agit de Collaboration Protocol Profile (CPP) et Collaboration Protocol Agreement (CPA) que nous détaillons dans ce qui suit : Collaboration Protocol Profile (CPP) décrit les capacités supportées par un partenaire commercial et les spécifications des Interfaces de Service. Ces dernières ont besoin d être «accordées» avant de pouvoir procéder à l échange de documents d affaires avec le partenaire commercial. Le CPP contient des informations essentielles au sujet du Partenaire Business, incluant de manière non limitative : des informations sur les coordonnées de contact, la classification par secteur d activité, les Processus Business supportés, les spécifications fonctionnelles d Interface et de Service de Messagerie. Les CPP peuvent également contenir des précisions sur la sécurité et des détails d'implémentation. Collaboration Protocol Agreement (CPA) : est un document qui représente l'intersection entre deux CPP et qui est l objet d un accord mutuel entre deux Partenaires Commerciaux quand ils prévoient d exécuter des opérations de Commerce Electronique en utilisant ebxml. Un CPA décrit le Service de Messagerie et les spécifications des procesus métiers qui sont agréés par deux ou plusieurs Partenaires Commerciaux. Un CPA contient les spécifications des besoins de l Interface de Service de Messagerie aussi bien que les détails d'implémentation relatifs aux processus métiers que les deux Partenaires Commerciaux conviennent d utiliser pour conduire leurs activités du e- commerce dans le B2B. La figure 6 illustre une architecture ebxml pour deux partenaires. 9 MIME: Multipurpose Internet Mail Extensions. 17

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Spécification des Processus Métiers Spécification des Documents affaires Composants CPP Interface Service Business Applications Business Services Répertoire/ Registre CPA CPP Interface Service Business Applications Business Services Service de messagerie Service de messagerie Partenaire A Partenaire B Figure 6: Architecture ebxml[31]. Un schéma de spécification des Processus Métiers (BPSS Business Process Specifications) permet de convertir les modèles de processus construits en UML en documents XML. En effet, la norme ebxml recommande l emploi de la notation graphique UML 10 et de la méthodologie des cas d utilisation pour représenter le processus métier. Cette spécification est à la version 2.04 et a été renommée ebbp (ebxml Business Process) et a été approuvé comme un standard par OASIS le 21 décembre 2006. Dans ebxml, un processus métier possède trois types de vues: les vues métiers, les vues fonctionnelles et les vues d implémentation. Les vues métiers et fonctionnelles sont des documents texte qui contiennent souvent des diagrammes UML. 1. La vue métier (Business Operational View : BOV) contient le scénario général des différentes interactions entre les acteurs lors des transactions. La BOV est avant tout un moyen pour homogénéiser les points de vues de différents acteurs industriels d un secteur donné. Elle est réutilisée par d autres acteurs d un secteur industriel voisin. Les spécifications produites par la vue métier sont stockées dans les registres ebxml et sont transformées d une manière semi-automatique en des documents XML. De ces documents sont extraits les protocoles et les contrats de collaboration sous la forme de DTDs. Ces derniers donnent la structure aux transactions effectuées lors de la phase d implémentation du processus métier. 2. La vue fonctionnelle (Functional Service View : FSV) précise les interactions et les besoins fonctionnels nécessaires à l implémentation pratique de BOV. La FSV 10 Unified Markup Language: http://www.uml.org. 18

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce exploite toutes les informations relatives aux processus métiers stockés dans les registres ebxml. 3. Les vues d implémentation sont décrites sous la forme de DTDs 11 afin de permette un usage immédiat dans l infrastructure XML des Web Services. Les processus métiers sont publiés dans les registres ebxml suivant le principe de séparation de ces vues. Les Collaborations des Processus Métiers dans l ebxml Une collaboration d affaire est un ensemble de rôles collaborant les uns avec les autres par l intermédiaire de transactions chorégraphiées lesquelles sont elles-mêmes constituées d échanges de Documents d Affaires. Une collaboration se compose de plusieurs activités. Une activité est celle d une transaction d affaire (par exemple : émission d une commande), ou d une autre collaboration binaire (par exemple: négociation d un accord). La collaboration constitue le premier engagement sur la définition de capacités. Cet engagement peut être déclaré par des Partenaires Commerciaux ebxml. Cette «déclaration de capacités» est facilitée par un profil distinct spécialement destiné à être publié ou référencé, dans un service d annuaire, comme un Registre ebxml, ou un tout autre service disponible. Les spécifications CPA - CPP incluent des annexes non normatives qui traitent de la négociation et de la composition d un CPA et présentent des recommandations pour la mise en œuvre des procédures de composition et de négociation. Les participants dans les transactions ebxml (trading partners) décrivent les processus métiers et le type de collaboration auxquels ils peuvent participer. Ceci est formalisé en utilisant le CPP qui est publié dans les annuaires ebxml. Le CPP permet de définir : 1. l identité du participant ; 2. les protocoles de transport et de sécurité requis et offerts ; 3. et les liens vers les schémas de processus métier. La recherche dans les annuaires permet de découvrir les profils appropriés à une transaction dans un processus métier. Ceci est fait de façon automatique par les moteurs de recherche, qui font partie des registres ebxml, en comparant les différents attributs des CPP. De ces comparaisons résulte un «dénominateur commun» entre les différentes contraintes des participants, comme par exemple, les protocoles à utiliser, les besoins en sécurité et la composition des messages. 11 DTD: Document Type Definition. 19

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce Le résultat de l analyse des profils est ensuite représenté en utilisant le CPA stocké par le programme Client et le Serveur qui règle l exécution des processus métiers correspondants. UMM UN/CEFACT Unified Modelling Methodology UMM [84] est une extension d UML 12. C est un profile UML utilisé pour décrire les composants UMM pour spécifier les stéréotypes spécifiques au domaine métier, qui supporte un processus métier complet, et la définition de l information pour décrire et analyser les processus métiers individuels. UMM est une approche pour définir les processus métiers inter-organisationnel. Il est utilisé pour modéliser la chorégraphie et l échange de données. Il peut être employé par les analystes métiers pour définir des frameworks de collaboration métier externe et interne. Il peut également être utilisé pour définir un framework de collaboration implémenté avec deux ou plusieurs parties. Le résultat final d une utilisation intégrée d UMM est la définition d un framework de collaboration métier. UMM a une compréhension des processus métiers et un méta-modèle de l information métiers aussi bien qu une méthodologie d analyse de processus. Il fournit une méthodologie et des composants qui supportent la capture des connaissances des processus métiers 2.2.3.2 RosettaNet RosettaNet [35] a été créé en 1998 pour formaliser en XML tous les éléments nécessaires à l'automatisation des services sur le Web dans les secteurs de l'électronique, des semiconducteurs et de l'informatique. Cet organisme a pour objet de formaliser le dialogue entre partenaires lors de transactions commerciales. Il vise à simplifier la mise en place et la gestion des processus métiers dans les secteurs industriels qu il regroupe. Pour que le dialogue entre partenaires ait lieu, l'architecture technique de RosettaNet définit trois notions : Des dictionnaires et des codes définissant le vocabulaire commercial employé dans les documents RosettaNet transitant sur le Web. Un modèle de processus métier appelé Partner Interface Process (PIP) : PIP est un catalogue le plus complet possible de processus préfabriqués qui est mis à la disposition des utilisateurs de RosettaNet (PIP Directory). Un cadre d'implémentation RosettaNet Implementation Framework (RNIF) : RNIF définit les choix techniques du consortium pour le format et l'échange des messages RosettaNet. 12 UML: Unified Modeling Language. 20

Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce L intérêt se porte principalement sur les dictionnaires qui constituent des descriptions sémantiques des objets d un domaine. RosettaNet a recours, pour la codification des sociétés et des produits, à des codes existants, également employés dans l'univers EDI. Il offre deux dictionnaires : RosettaNet Technical Dictionnary (RNTD) qui articule les descriptions des propriétés techniques et de relations en vue de faciliter la création de catalogues, la création de documents de spécifications, et l'alimentation de bases de données. RosettaNet Business Dictionnary (RNBD) qui contient des descriptions d'objets métier communs aux différents processus PIP (bons de commande, facture, etc.) La création et le traitement de l'information commerciale mettent en jeu les dictionnaires et les codes RosettaNet pour assurer un partage et une compréhension des documents échangés. Les échanges de messages RosettaNet sont pilotés par le PIP qui dirige la transaction entre partenaires RosettaNet. Même si les processus métiers représentés dans RosettaNet s'inspirent des méthodes de production et de distribution en informatique et en électronique, un certain nombre de notions trouve un champ d'application plus vaste dans le domaine du commerce électronique en général. Ceci explique les rapprochements entre RosettaNet et ebxml pour l'harmonisation des définitions et du vocabulaire XML. 3. Conclusion Ce chapitre s est porté sur le B2B du e-commerce, en décrivant ces concepts de base, à savoir l intégration et l interaction B2B. En dénotant l architecture, quelques technologies et les standards permettant l interaction B2B. Notre intérêt va s orienter vers les processus métiers qui représentent la composante clé de la couche externe de l échange inter-entreprise (B2B). Ainsi, le chapitre suivant va porter sur les Processus Métiers et plus précisément leur collaboration qui représente un défi dans le e-commerce du B2B. 21

Chapitre II: La collaboration des Processus Métiers Chapitre II : La collaboration des Processus Métiers Résumé: Ce chapitre décrit la collaboration des Processus Métiers. Nous commencerons par la définition des Processus Métiers, ensuite nous décrirons les différents standards permettant sa définition. Finalement, nous décrirons les différentes solutions existantes de collaborations de Processus Métiers. 1. Introduction Aujourd hui plus que jamais, les organisations de toute taille se développent dans le monde entier: fournisseurs dans un pays, clients dans un autre. C est la raison pour laquelle, il est devenu vital de faire collaborer et d intégrer tous ces partenaires dans un environnement métier. Nous nous intéressons dans ce qui suit à la collaboration des processus métiers. Ce chapitre va donc porter en premier lieu sur la définition des processus métiers et les différents langages les décrivant. Ensuite, les différentes solutions et propositions faites par des chercheurs et industriel pour permettre une collaboration métier efficace. 2. Définition des Processus Métiers Définition 1 : Un Business Process ou Processus Métier ou encore processus affaire est un ensemble de règles métiers (business), de définitions d activités et d événements déclencheurs qui fournissent un contexte d échange d information [42]. Réservation d une chambre d hôtel (comme illustré dans la figure 7) est un exemple de processus métier. L élément déclencheur est représenté par l individu, {réserver une chambre d hôtel, débiter de la carte de crédit et la notification au client} représente les activités et les règles métiers sont désignés par la disponibilité ou non d une chambre d hôtel. Demande Réserver une chambre d hôtel Non Fin Résultat Oui Débiter de la carte de crédit Notifier au client Figure 7: Exemple d'un processus métier. Définition 2 : Un Processus Métier selon [59] est une unité persistante d un travail pouvant avoir jusqu à 100 transactions IT 13. Il est déclenché par un événement métier tel que 13 IT : Information Technology. 22

Chapitre II: La collaboration des Processus Métiers l invocation, requête pour proposition ou une requête pour un transfert de fonds. Le processus est conduit par des règles métiers qui déclenchent les tâches et les sous-processus, avec chaque transition d état exécutée dans une transaction et auditée pour des raisons métiers. Les tâches et les sous-processus sont assignés à des ressources qui sont des unités organisationnelles capables et autorisés à jouer des rôles spécifiques dans le processus. La définition des règles, des tâches, des sous-processus, et des stratégies de ressources constitue une description de processus. L exécution d un processus métier consiste en l invocation des services métiers existants, qui peuvent résider n importe où. Définition 3 : Un Processus Métier selon R.Gong [33] est un ensemble d activités conçues pour produire des outputs spécifiques pour un marché ou un client particulier. Il peut être définie sur la base de trois dimensions : 1. Entités : les processus prennent place entre les entités organisationnelles. Il peut être inter-organisationnels, inter-fonctionnel ou encore entre personnes. 2. Objets : les processus sont le résultat d une manipulation d objet. Ces objets peuvent être physiques ou informationnels. Notifier au client (figure 7) est un exemple d objet. 3. Activités : les processus peuvent impliquer deux types d activités : les activités opérationnels et les activités de gestion. 3. Le cycle de vie d un Processus Métier Intalio 14 [46], a présenté les quatre étapes constituants le cycle de vie d un processus métier. Ces étapes sont illustrées dans la figure ci-dessous. Modélisation Déploiement Exécution Interaction Figure 8: Cycle de vie d'un Processus Métier [46]. Première phase: phase de modélisation du processus métier. Elle représente la phase où l importation des définitions des processus métiers dans les outils 14 Intalio: Acteur spécialisé dans les solutions Open Source de gestion des processus métier et acteur historique sur la scène de la gestion des processus d'entreprise 23

Chapitre II: La collaboration des Processus Métiers techniques est possible, afin d ajouter le lien avec les applications du SI 15. Les capacités de modélisation des outils devraient permettre de déployer directement les processus modélisés sans passer par une phase d implémentation. Seconde phase : Déploiement du code réalisé durant la phase précédente. Troisième phase : consiste en l exécution des applications existantes de l entreprise. Quatrième phase : consiste en l interaction des utilisateurs avec ce processus. Une fois le processus déployé, la phase d interaction permet de l optimiser. Cette phase permet d identifier les modifications à effectuer. Pour les réaliser, on entre alors dans une autre phase de modélisation, et ce cycle se répète. Généralement, après trois itérations, il est plus simple de re-développer l application hébergeant le processus que d en modifier l implémentation. 4. La gestion des Processus Métier (Business Process Management : BPM) Généralement, les systèmes d affaire qui supportent des activités d affaires importantes comprennent des processus métiers. Ces processus métiers nécessitent une gestion et une intégration rigoureuse avec les nouveaux systèmes des partenaires. Pour Gartner, le Business Process Management ou encore le système de gestion de processus (BPM) est devenu une véritable discipline de management qui considère les processus métiers comme des actifs de l entreprise à concevoir, à re-définir ou à exploiter afin d en améliorer l agilité et la performance opérationnelle. Le BPM inclut la capacité de découvrir, de concevoir, de déployer, d exécuter, d interagir avec, d optimiser et d analyser les processus métiers [50]. Il vise également à formaliser, à organiser et à contrôler les activités d'une entreprise. Lorsque les processus sont suffisamment bien définis et modélisés. Le gestionnaire des processus (BPM) [59] gère l état du processus métier et route les requêtes parmi les applications participantes. Le plus souvent, la séquence des étapes à être traversée dans l exécution d un processus métier est définie avant que l instance du processus ne soit initiée. Durant l exécution, un événement déclenche le système de gestion des processus pour créer une instance de processus, le système de gestion des processus ainsi coordonne les étapes d exécution, surveille et enregistre l historique. Selon [27] et [48], la gestion inter-entreprise des processus métiers comporte deux types de processus métiers : les processus métiers publics et les processus métiers privés. 15 SI : Système d Information. 24

Chapitre II: La collaboration des Processus Métiers 1. Un processus public définit un échange de messages d une organisation avec ses partenaires à travers un protocole d échange. 2. Un processus privé décrit des exécutions d activités interne supportées par les processus privés. Il peut également interagir avec des applications «back-end» (Backend est une application ou un programme qui sert indirectement dans le support des services front-end. Ce dernier est une application avec laquelle l utilisateur interagit directement) à travers des adaptateurs d applications. Ces deux processus métiers (privé et public), agissent à travers des traducteurs (wrappers) qui consistent en des activités prédéfinies dans les processus métiers privés pour envoyer /recevoir des messages provenant/destinés aux processus métiers publics. La séparation entre les composants d une application B2B (à savoir : les processus métiers privé et publics, les règles métiers et les systèmes «back-end») contribue au passage à l échelle de la collaboration. Et la séparation entre un processus métiers public et un processus métiers privé fournit un plus grand degré d autonomie. Cependant, les changements s effectuent de la façon suivante [36] : - Les changements relatifs aux interactions (exemple : changement de format des messages entrants et sortants) entre un processus publique (ou application «backend») et un processus privé peut requérir la modification de certains traducteurs. - Le support d un nouveau protocole d interaction nécessite seulement la création de nouveau processus publique et de nouveaux traducteurs de processus (wrappers). - Le support de nouvelles applications «back-end» nécessite la création de nouveaux adaptateurs d applications. - La création d une nouvelle relation avec de nouveaux partenaires peut nécessiter de nouveaux ajustements. - Si le partenaire ne se conforme pas à un protocole d interaction déjà supporté, alors un nouveau processus public doit être créé pour supporter le protocole utilisé par le nouveau partenaire. Yphise 16 nomme TIBCO 17 meilleur éditeur de solution BPM (en Novembre 2006) dans un comparatif certifié ISO 9001:2000 réalisé par le cabinet de conseil. Ainsi, TIBCO iprocess Suite devance les solutions développées par les autres grands éditeurs. 16 La société Yphise est certifiée ISO 9001 dans l évaluation de progiciels. Cette norme internationale de la qualité garantit l'indépendance et le centrage sur les préoccupations des grandes entreprises. Le métier d'yphise est d'identifier et d évaluer les progiciels qui méritent un investissement en grande entreprise. Ses publications font référence dans le monde. Yphise évalue 150 progiciels par an depuis 1985. 25

Chapitre II: La collaboration des Processus Métiers 5. Les standards de modélisation des Processus Métiers Des standards et des langages pour la modélisation des processus métiers existent tel que : 5.1 Business Process Modeling Notation (BPMN) Le BPMI 18 issue d'un regroupement d'entreprises, a développé le standard Business Process Modeling Notation (BPMN) [71]. Ce dernier a pour objectif primaire de fournir une notation compréhensible par tous les utilisateurs métiers; des analystes métiers qui créent des drafts initiaux de processus, aux développeurs techniques responsables de l implémentation de la technologie qui exécute ces processus, et finalement, aux gestionnaires et ceux qui surveillent ces processus. Ainsi, le BPMN crée un lien standardisé entre la conception et l implémentation des processus. Un autre objectif, mais qui n est pas moins important, est d assurer que les langages XML conçus pour l exécution des processus affaires, tels que le BPEL (qui sera définit dans la section suivante), puissent être visualisés avec une notation orientée métier. La modélisation des processus métiers est utilisée pour communiquer une large variété d information à une large variété d audience. BPMN est conçu pour couvrir plusieurs types de modélisation est de permettre la création des processus métiers de bout en bout (end-to-end). Les éléments structurels du BPMN permettent aux observateurs d être capable de différencier facilement entre les sections d un diagramme BPMN. Il y a trois types basiques de sous modèles dans un modèle BPMN bout en bout, à savoir, les processus métiers privés, les processus publics et la collaboration des processus. Cependant, le BPMN ne prend pas en considération dans la modélisation les règles métiers, la stratégie, les modèles de données et d information et les ressources et structures organisationnelles. 5.2 Unified Modeling Language (UML) 19 Unified Modeling Language est un langage de représentation d un modèle, d une structure, appliqué à la programmation orientée objet. UML comporte différents diagrammes tel que les diagrammes de séquence et les diagrammes d activités. 17 TIBCO Software Inc. (NASDAQ:TIBX) est un éditeur de logiciels d'intégration et de gestion des processus métier dans le domaine de l'information en temps réel. L'activité en temps réel permet aux entreprises de saisir sur-le-champ les changements et les opportunités dès leur détection. http://www.tibco.com. 18 Business Process Management Initiative. 19 UML. http://www.uml.org. 26

Chapitre II: La collaboration des Processus Métiers 6. Les concepts de bases pour la description des Processus Métiers Dans ce qui suit, nous présenterons brièvement deux concepts sur lesquels reposent la description des processus métiers à savoir XML et les web services. 1. XML (extensible Markup Language) : modèle de données semi-structuré, dont le premier draft a été publié en 2000 par le W3C 20. il se base sur HTML et le SGML. Il représente un format d échange universel. 2. Web Services: sont décrits grâce à des fichiers WSDL (Web Service Definition Language) enregistrés dans un répertoire UDDI (Universal Description, Discovery, and Integration) et communiquent grâce au protocole SOAP. (Annexe A). o L orchestration et la chorégraphie des Web Services: Les termes orchestration et chorégraphie décrivent deux aspects de création de processus métiers à partir des web services composites [78]. L orchestration et la chorégraphie sont utilisées dans les processus métiers et les systèmes de gestion de processus métiers [50] : 1. L orchestration: décrit l interaction entre web services, en incluant la logique affaire (business) et l ordre d exécution des interactions. Ces interactions peuvent traverser des applications ou/et des organisations, et résulte dans un modèle de processus à multi étapes transactionnel et de longue durée [81]. Les orchestrations sont définies par le consortium W3C comme étant «le modèle des interactions que doit respecter un agent Service Web pour atteindre son but». 2. La chorégraphie: trace la séquence des messages qui peuvent impliquer de multiples parties et de multiples sources, en incluant les clients, fournisseurs et partenaires. La chorégraphie est typiquement associée à l échange de messages publics qui se produisent entre de multiples web services plutôt qu à un processus métier spécifique qui est exécuté par une seule partie [81]. La figure ci-dessous, décrit l orchestration et la chorégraphie. L orchestration se réfère à un processus exécutable. Par contre, la chorégraphie trace les séquences de messages entre parties et ressources [78]. 20 W3C: World Wide Web Consortium 27

Chapitre II: La collaboration des Processus Métiers Figure 9: Orchestration versus chorégraphie [78]. La différence entre la chorégraphie et l orchestration a été soulignée dans [81]. L'orchestration se rapporte à un processus exécutable d'affaires qui peut agir l'un sur l'autre avec des services Web internes et externes. Pour l'orchestration, le processus est toujours commandé par la perspective d'une des parties d'affaires. La chorégraphie est plus collaborative par nature, dans laquelle chaque partie concernée dans le processus décrit le rôle qu'elle joue dans l'interaction. 7. Les standards de description des Processus Métiers Cette section comportera les différents standards de description des processus métiers, les plus référencés dans la littérature tel que : XLANG, WSFL, BPEL4WS, BPML, WSCI. 7.1 XLANG C est un format proposé par Microsoft, en 2001, pour représenter en XML l orchestration d activités qui constituent un processus métiers. XLANG est le format intermédiaire de stockage de l environnement BizTalk server 21. Ces documents XLANG, ou encore appelé schedules : sont exécutés par le serveur BizTalk en phase de production. XLANG s appuie sur WSDL en réutilisant un certain nombre de ses concepts [38]. Le document XLANG [37] comprend : 1. Les actions XLANG : elles sont au nombre de quatre. Elles peuvent être élémentaires dans la représentation du workflow entre participants. Citons comme exemple : l action raise pour signaler les défaillances, ou encore, Operation pour l échange de message référençant le port d un service donné. 2. Le contrôle XLANG : consiste en des commandes de contrôle de l enchaînement de l exécution des actions. Par exemple : la commande sequence permet l exécution séquentielle d une ou de plusieurs actions. 21 Microsoft BizTalk Server http://www.microsoft.com/biztalk/default.mspx 28

Chapitre II: La collaboration des Processus Métiers 3. Les corrélations de messages : il est possible d associer des champs d information supplémentaires à un message d une opération. Ces champs qu ils soient simples ou complexes sont utilisés pour corréler des messages entre eux. 4. Le contexte : le contexte est un élément XLANG qui permet de définir des variables locales et des transactions liant les actions ou les combinaisons d actions. Les variables locales sont constituées des définitions des corrélations et des références aux ports WSDL qui sont utilisées dans les actions. 5. Les transactions XLANG : une transaction préserve l intégrité des données qu elle manipule. Dans le cas de transactions dites longues, où les suspensions et les reprises d exécution peuvent être beaucoup plus espacées dans le temps, les états même partiels doivent être sauvegardés pour éviter que leur verrouillage durable n affecte d autres transactions. 6. Les contrats : précisent comment lier deux ports différents des service XLANG. Pris ensemble avec les définitions des comportements XLANG, les contrats constituent la définition complète du workflow entre les différents services. La définition d un contrat XLANG en XML consiste en général à importer la définition XLANG des deux services à relier et à spécifier comment les opérations de sortie de l un aboutissent aux opérations d entrée de l autre. 7.2 Web Service Flow Language (WSFL) Proposé par IBM, le WFSL [40] est un langage de description de combinaison des Web Services de façon utile. Deux façons de combiner les services sont définies : 1- Des modèles de circuit (Flow Model), où un circuit représente une séquence à exécuter pour qu'un processus métiers puisse être réalisé ; 2- Des modèles globaux (Global Model), où la perspective est celle des régularités dans l'interaction entre les Web Services dans le contexte de collections de services typiques. Ces interactions sont réglées par des liens entre des services, avec un lien pour chaque opération possible entre deux services dans une collection. Ce réglage peut être adapté soit à des interactions dans des hiérarchies, soit à des interactions collaboratives entre pairs. 7.3 Business Process Execution Language For Web Services (BPEL4WS) En 2003, la spécification BPEL4WS1.1 [36] a émergé après la convergence de deux spécifications à savoir le WSFL et le XLANG. Le Business Process Execution Language for Web Services (BPEL4WS) fournit une notation XML et une sémantique pour la spécification du comportement des processus métiers basés sur les Web Services. Un processus BPEL4WS est défini en terme de ses interactions avec 29

Chapitre II: La collaboration des Processus Métiers ces partenaires. Un partenaire peut fournir des services au processus, nécessiter des services des processus, ou encore, participer à l interaction avec le processus [39]. Le modèle BPEL4WS permet la description des processus métiers en deux aspects : Un processus exécutable : qui décrit le comportement actuel d un participant dans une interaction métier. Un processus abstrait : un processus métiers abstrait comprend des descriptions pour les protocoles métiers pour définir les messages échangés sans révéler le comportement interne. Remarque : Une nouvelle version du BPEL, a été publiée le 31 Janvier 2007, appelé WS- BPEL v2.0 22. 7.4 Business Process Modeling Language (BPML) Développé par BPMI 23, la spécification BPML fournit un modèle abstrait pour l expression des processus métiers et des entités supportées. BPML [69] définit un modèle formel pour l expression des processus métiers abstraits et exécutables qu adresse tous les aspects des entreprises des processus métiers, incluant les activités de complexités variées, des transactions de leur compensations, gestion des données, concurrent, gestion des exceptions et les sémantiques opérationnelles. BPML peut aussi fournir une grammaire sous forme de Schéma XML pour permettre la persistance des échanges et des définitions à travers les systèmes hétérogènes et les outils de modélisations. 7.5 Web Service Choreography Interface (WSCI) Web Service Choregraphy Interface (WSCI) [80], co-développé par BEA, Intalio, SAP et Sun. WSCI décrit comment les opérations des services web (tel que ceux définissent par WSDL) peuvent être chorégraphiés dans le contexte d échange de message dans lequel les web services y participent. Les interactions entre services (soit dans un contexte métier ou pas) suivent toujours et implémentent l échange chorégraphié de message (processus). WSCI est la première étape permettant le mapping des services comme composants réalisant ces processus. WSCI décrit aussi comment la chorégraphie de ces opérations doit exposer les informations pertinentes, tel que la corrélation de message, la gestion des exceptions, la description des transactions et les capacités de la participation dynamique. Il ne suppose pas que les web services soient de différentes entreprises, comme dans le B2B ; il peut être 22 OASIS. Web Services Business Process Execution Language Version 2.0. OASIS Standard. 11 April 2007 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html 23 Business Process Modeling Initiative (BPMI): est un consortium de standardisation. La branche BPM a fusionné avec celle de l'object Management Group (OMG) en juin 2005 pour former Business Modeling & Integration (BMI) Domain Task Force (DTF). 30

Chapitre II: La collaboration des Processus Métiers également utilisé pour décrire les interfaces des composants que représentent les unités organisationnelles internes ou d autres applications dans une entreprise. WSCI n adresse pas la définition de la conduite de l échange de message ou la définition du comportement interne de chaque web service. WSCI décrit les inter-dépendences parmi les opérations des web services pour que n importe quel client puisse: Comprendre comment interagir avec un tel service dans le contexte du processus donné. D anticiper les comportements attendus d un tel service à n importe quel point dans le cycle de vie du processus. Être capable de décrire l interface dynamique d un service dans le contexte d un processus particulier qui permet de développer une forme abstraite de l implémentation et de se focaliser sur le rôle joué des web service dans un tel processus [80]. Cependant, comme souligné par Dario Wiser, responsable du marketing produit chez Sun Microsystems «WSCI permet d'utiliser les services web au sein de processus complexes. Pourtant, WSCI n'est pas un concurrent des dialectes existants» [80]. 7.6 Web Service Choreography Description Language (WS-CDL) En 2004, la convergence de WSCI 24 et le WSCL 25 a donné lieu au Web Services Choreography Description Language (WS-CDL) [49]. WS-CDL est un langage de description de la chorégraphie de web services qui se base sur le langage XML. Ce dernier, décrit la collaboration des web service à travers les entreprises participantes. Cette collaboration définit le comportement observable commun des entreprises participantes, dont l échange de message est ordonné et synchronisé résulte dans l alignement de leur information partagée. Le contrat entre plusieurs participants est décrit par la chorégraphie. Cette dernière décrit la composition d une perspective globale. WS-CDL a pour objectif d aboutir à la composition des collaborations interopérable entre n importe quel type de participant, sans considérer la plateforme ou le modèle de développement utilisé. Remarque : Une comparaison entre les différents formats d échange de BPM comprenant des langages de description des processus métiers, a été présentée dans [52] mettant en exergue les points forts et les points faibles de chacun selon des critères tels que le contrôle de flux, les rôles, les événements, les transactions, les exceptions, et les données statistiques que les auteurs ont définit. 24 WSCI: Web Service Choreography Interface. 25 WSCL: Web Service Choreography Language. 31

Chapitre II: La collaboration des Processus Métiers Une synthèse des standards émergeant qui illustrent la chorégraphie à travers le BPEL et WSCI est présentée dans [81]. 8. La collaboration des Processus Métiers Le développement d une collaboration réussie nécessite de suivre des exigences chorégraphiques pour assurer la cohérence parmi les processus métiers individuels à travers des organisations. Il nécessite aussi de rencontrer les exigences organisationnelles pour assurer que chacun des processus métiers des organisations s exécute selon des règles métiers et se conforme à ce qui est spécifié du point de vue de la collaboration [63]. Une collaboration entre entreprises requiert un mécanisme qui permet aux entreprises participantes d approuver la description du processus métier commun et des données à être échangées durant l exécution du processus [59]. La collaboration entre entreprises au niveau processus métier se définit en trois étapes ([55], [61], [60], [63] et [64]): 1 ère étape : Définition d un processus métier collaboratif approuvé par tous les participants. La définition de ce dernier a été a été avancée dans [61] en apportant des extensions à la définition de base du processus : - Un processus collaboratif comporte une liste de rôle de processus qui indique la logique des participants. - Un nœud de travail qui représente une tache associée à une activité, i-e une partie du travail qui contribue à l accomplissement du processus, doit correspondre à un rôle dans le processus. Une activité a également un rôle appelé rôle de l activité. Cette notion de rôle d activité existe dans les spécifications des processus métiers. 2 ième étape : Identification des processus métiers publics dans le processus collaboratif au niveau de chaque participant. 3 ième étape : Mise en correspondance des processus publics avec les processus privés de chaque participant. Différentes topologies de la collaboration métier ont été présenté par Paul Grefren [62]: 1. Collaboration Horizontale : une collaboration de nature pair-to-pair (P2P), qui est représentée par la formation d une coopération dynamique de réseaux métiers dans lesquels les partenaires implémentent les fonctions centrales des affaires. 2. Collaboration Verticale : se base sur le paradigme d «Outsourcing» ou d externalisation, des processus métiers, en délégant des activités métiers secondaires à des fournisseurs de services qui sont spécialistes. 32

Chapitre II: La collaboration des Processus Métiers Finalement, dans [33], ont été définit les aspects qui augmentent l efficacité de la collaboration des processus métiers. Ces aspects consistent en : 1. L interopérabilité basée sur l information : elle concerne les standards pour le format de l information tel que XML. 2. La coordination basée sur les ressources: elle concerne le contrôle et l ordonnancement des ressources partagées tel que les employés. 3. La collaboration basée sur les règles métiers: elle concerne les mécanismes de coordinations de processus tel que le partenariat de confiance. 9. Les solutions de collaboration des Processus Métiers Nous allons présenter dans cette section, les différentes solutions de collaboration des processus métiers. Ces solutions se basent sur: la chorégraphie et l orchestration, le workflow, les extensions du standard ebxml et autres (enveloppe SOAP, ). Chorégraphie et orchestration: Pour accomplir un but métier commun parmi les entreprises, l orchestration et la chorégraphie peuvent être employées pour faciliter les interactions parmi les participants (distribués et hétérogènes) dans lesquelles aucun participant n a un contrôle complet. La collaboration métier doit avoir les caractéristiques incluant: le couplage faible, l interaction sur demande et l adaptation rapide à des changements fréquents. La solution par la chorégraphie de service peut réaliser une collaboration e-business rapide et flexible parmi les entreprises [60]. La chorégraphie décrit la collaboration métier au niveau global, en capturant toutes les interactions entre organisations. Les organisations participantes peuvent ainsi dériver leurs comportements publics pour supporter les interactions spécifiées dans la chorégraphie globale [63]. Intégration des workflows par une chorégraphie de processus métiers : Dans [55], Jung et Al ont proposé une méthodologie pour réutiliser les workflows internes de l entreprise d une manière efficace et pour contrôler automatiquement les interactions métiers. Cette méthodologie se base sur la chorégraphie des processus métiers. Elle a été définit comme une procédure qui intègre un workflow existant dans une logique affaire et génère un processus métier collaboratif. Dans leur approche, la collaboration des processus métiers est caractérisée par un contrat particulier parmi les partenaires métiers. Le contrat a une procédure logique parmi les processus internes. Ce contrat peut être représenté sous forme de processus métier. La procédure logique définit des transactions d affaire de chaque partenaire qui y participe ou qu il exécute dans le but de la collaboration. Cette procédure logique peut 33

Chapitre II: La collaboration des Processus Métiers également être une séquence de logique métier contenant des éléments de formats de données, de points finaux logiques et du niveau de sécurité. La chorégraphie des processus métiers s effectue en quatre étapes : Etape 1: Tous les participants établissent des contrats d interopérabilité et extraient la logique métier. Ensuite, ils conçoivent un contrat commun pour un processus métier collaboratif. Etape 2: Chaque participant valide son propre processus interne et prépare les processus internes nécessaire pour la logique métier. Etape 3: Les participants analysent les relations entre les contrats métiers communs et leur propre processus interne. Etape 4: Chaque participant définit une interface de protocole qui spécifie formellement les interactions entre le processus contrat et les propres processus interne des participants. Un framework de collaboration métiers : Dans cet article [63], un framework de collaboration métier a été proposé. Ce dernier se base sur une approche orientée chorégraphie globale. Ce framework a été appliqué à un cas réel du «Capital Market», où les trois couches du modèle ont été implémentées. Ces trois couches sont : Couche 1 : Détermination du comportement global : a. Fournit une liste de toutes les organisations impliquées dans la collaboration métier. b. Détermine la séquence des interactions à archiver dans le but de la collaboration métier. Couche 2 : Identification du comportement exposé : Il déduit le comportement public de chaque organisation impliquée dans la collaboration affaire à partir du comportement global. 1. Dans chaque interaction décrite dans le comportement global : - Si l organisation est identifiée comme un rapporteur de message, il est requis de rajouter une activité «receive» à son comportement exposé afin d extraire le message. - Si l organisation est identifiée comme un invocateur de message, il est nécessaire de rajouter une activité «invoice» et «response» à son comportement exposé afin d envoyer le message. 2. Pour chaque organisation, organiser toutes les activités interagissant par flux d activité basées sur le même ordre des interactions correspondants. La liste des activités dans le comportement exposé de chaque organisation peut être vue comme un processus abstrait fournit par cette organisation. Ce processus décrit la séquence de la logique du processus qui peut être exécuté par les processus métiers internes. 34

Chapitre II: La collaboration des Processus Métiers Couche 3 : Implémentation des processus métiers Comme le processus abstrait de chaque organisation est décrit par un comportement exposé, les services internes nécessaires peuvent être identifiés à partir du comportement interne. Ce processus abstrait peut ainsi être transformé en processus métier exécutable. Une plateforme de collaboration et d intégration B2B du e-commerce : Bhaskaran et Al ont proposé dans [56], une plateforme de collaboration e-commerce du B2B ainsi qu une plateforme d intégration e-business. Cette plateforme comprend un broker de processus métiers, un broker de message, un serveur de sécurité et un gestionnaire d interaction. Elle est conçue comme une collection de frameworks coopératifs (un framework pour la gestion des interactions, un framework pour l accès..). Le framework pour l intégration des processus métiers est réalisé dans le broker des processus métiers. Ce dernier a la même fonction générale que les messages brokers ou encore que les courtiers d information. Les brokers des processus métiers ont été définis dans [58] comme étant des serveurs agissant à titre d intermédiaire entre plusieurs applications. En plus de la transmission des messages, ils peuvent transformer le schéma du message et en changer le contenu afin que les messages soient compréhensibles par l application qui reçoit le message. Le broker des processus métier héberge les composants de la solution qui sont responsables de la gestion de l état métier et de l orchestration qui dépend de l état des processus métiers. Le broker des processus métiers aussi connu comme le Business Flow Management ou BFM, externalise les définitions du flux (le contrôle de flux et les données du flux) et les règles métiers qui conduisent la chorégraphie des processus. Le Business Flow Management (BFM) modélise une longue exécution des processus métiers comme des graphes de flux. Un moteur workflow y est inclut pour fournir un environnement d exécution pour ces processus. Chorégraphie de Service pour une collaboration inter-entreprises : Une autre solution a été proposée par Xiaoqiang et Al dans leur article [60], qui consiste en une chorégraphie de service pour une collaboration entre organisations en préservant l autonomie locale de leur propre processus métier. Une chorégraphie centralisée de service de processus est construite pour la spécification d un processus métier global. Ce dernier est transformé en des processus métiers décentralisés parmi les participants pour des interactions Pair-à-Pair (P2P). Pour chaque participant, une dépendance de données basée sur un modèle de médiation de données est développée pour faciliter l adaptation entre le processus métier pré-établis et ses processus de chorégraphies centralisés correspondants. 35

Chapitre II: La collaboration des Processus Métiers Cette médiation assure la confidentialité et l autonomie des processus métiers locaux et l adaptabilité de la chorégraphie de processus. Figure 10: Le modèle de médiation [60]. Cette solution concerne la collaboration métier inter-entreprise basée sur la chorégraphie de service qui consiste en la : 1. Construction d une chorégraphie centralisée de processus pour une collaboration métier : Le processus métier global est utilisé pour spécifier le but global du processus qui peut être vu comme une chorégraphie centralisée de processus. D une part, toutes les entreprises impliquées conviennent sur la structure du processus métier global. D autre part, les détails des services ou bien les données privées sont préservés. 2. Transformation du processus centralisé en des processus décentralisés : Le processus centralisé démontre un modèle conceptuel du comportement observable de chaque service participant dans l interaction. L interaction est étudiée d une manière décentralisée. La décomposition automatique du processus centralisé en des sous processus est vu comme un processus de chorégraphie décentralisé. Chaque sousprocessus contient toutes les activités dont les participants en sont responsable et représente les aptitudes métiers que les participants doivent fournir. Le processus résultant, sert comme une vue abstraite du processus de l orchestration interne. La partie abstraite est utilisée seulement pour organiser l interaction avec d autres entreprises et n interfèrent pas avec l exécution du processus de l orchestration interne. 3. Médiation du processus chorégraphie décentralisée avec l orchestration des processus internes : Le processus de la chorégraphie décentralisé représente le pattern d interaction avec lequel l entreprise coopère avec d autres pairs. Ce processus est mis en correspondance avec le processus d orchestration actuel afin d exécuter 36

Chapitre II: La collaboration des Processus Métiers l interaction et l échange correcte des données. La médiation est l élément clé d une interaction flexible à travers les frontières de l entreprise pour préserver l autonomie des processus internes. Workflow : Les systèmes de workflow ont été conçus pour la gestion des processus intraentreprise. L utilisation de ces systèmes pour gérer des processus inter-entreprise engendre des difficultés considérables. Ces difficultés concernent la gestion des firewalls, la sécurité, la confidentialité et le partage de données [61]. Les systèmes de gestion de workflow doivent assurer une interaction entre les processus métiers des différentes organisations participantes et une intégration de leurs infrastructures, en préservant leur autonomie et l aspect concurrentiel. Pour accomplir ces objectifs, il est important de permettre l interopérabilité des systèmes de gestion de workflow. Cette interopérabilité doit adresser [64] : 1. La sémantique concernant l interopérabilité des processus métiers, tel que les relations entre les rôles d un processus métiers d une organisation et les taches métiers dans un processus d une organisation partenaires. 2. L intéroperabilité de l interface du niveau, permettant les systèmes WFMS d échanger des données et des événements. Un framework de processus collaboratif : Un framework de processus collaboratif a été proposé dans [61] -par les laboratoires HP- pour étendre la technologie de gestion centralisée des processus. La coopération de multiples entreprises est souvent basée sur des interactions P2P plutôt qu une coordination centralisée. Comme conséquence, l architecture de la gestion conventionnelle centralisée des processus ne s adapte pas au B2B du e-commerce. D où la définition d un processus collaboratif qui inclut de multiples parties, chacune jouant un rôle dans le processus. Deux aspects distinguent le modèle de processus collaboratif d un modèle centralisé conventionnel de processus : 1. La définition du processus collaboratif se base sur un protocole d interaction métier communément approuvé. 2. L exécution du processus n est pas exécutée par un moteur workflow 26 centralisé mais par de multiples moteurs d une manière collaboratives. Chacun de ces moteurs représente un participant dans le processus métier. L architecture des systèmes de 26 Un moteur de workflow ou Workflow Engine [72] est un service logiciel ou un moteur qui fournit un environnement d exécution pour une instance de workflow. Bonita et OpenCS sont des exemples de moteurs de workflow. 37

Chapitre II: La collaboration des Processus Métiers gestion de processus centralisés ne s adapte pas aux échanges inter-entreprises dans le e-commerce. Figure 11: Gestion P2P du processus collaboratif [61]. Leur solution définit un gestionnaire de processus collaboratif pour supporter une collaboration décentralisée. Elle gère également des processus pair-à-pair pour une collaboration intra-entreprise au niveau processus métier. Leur approche comporte: - Un processus collaboratif qui n est pas manipulé par un moteur workflow centralisé mais par de multiples CPMs (CPM : Collaborative Process Management), chaque CPM représente un participant dans le processus métier. Chaque CPM est utilisé pour ordonnancer, dispatcher et contrôler les taches du processus dont le participant en est responsable. - Les CPMs interopérent à travers un protocole de messagerie inter-cpm pour synchroniser leur progression dans l exécution du processus. L exécution d un processus collaboratif consiste en un ensemble d instances de processus pair, exécutées par les CPMs des parties participantes. Ces instances partagent la même définition du processus mais ont des propriétés additionnelles (par exemple le rôle: acheteur, vendeur) et peuvent avoir des données du processus privés et des sous-processus privés. Durant l exécution du processus métier collaboratif, ses instances doivent être spécifiées et limitées au rôle du participant pair concerné. En plus, un identificateur logique de cette exécution doit être obtenu (pour corréler et synchroniser les multiples instances paires de l exécution d un seul processus collaboratif). Une activité est confiée à un agent logiciel ou à utilisateur humain pour l exécution. Sur l accomplissement de cette activité, un message de retours de la tache est renvoyé et utilisé pour déclencher l étape suivante dans l exécution du processus. 38

Chapitre II: La collaboration des Processus Métiers Un framework de processus métier : Un framework de processus métier [64] a été proposé par Karsten et Al. Ce framework adresse des problèmes très importants dans la collaboration e-business tels que la confidentialité des processus métiers, la coordination de l interaction des partenaires affaires selon les stratégies organisationnelles et assurer que l interaction entre partenaires soit dynamique et adaptable. Les organisations qui participent dans un partenariat étroit B2B sont confrontées à une tension entre l harmonisation des processus internes avec leurs partenaires et au même temps garder leurs processus métiers confidentiels. Pour cela, les auteurs de cet article ont proposé d encapsuler et d exposer des processus métiers comme un service de processus métiers. Cette solution permet de garder les parties d un processus métier d une organisation confidentielles. Ce service de processus métier n est autre que l abstraction des processus actuels offerts par une organisation. Ainsi un service de processus métier peut comporter plusieurs processus privés nécessaires. Les événements métiers sont utilisés pour échanger des informations entre les taches du processus métier privé et les taches du processus partagé. L architecture du framework de processus métier représente l exécution du comportement des processus métiers, et de leurs applications, du broker et d une passerelle de processus métier. Le broker est une instance centrale qui coordonne l interaction des partenaires participants. Il est un composant orienté workflow qui exécute les processus métiers partagés, en utilisant un moteur workflow. Le concept du processus métier partagé a été introduit et utilisé dans ce framework. Ce concept fait référence aux services de processus métiers en connectant les processus métiers privés dans un scénario métier à travers les organisations. Figure 12: Architecture du framework du Processus Métier [64]. 39

Chapitre II: La collaboration des Processus Métiers Le processus métier partagé spécifie les activités que chacune des parties requiert pour exécuter comme agréée dans leurs contrats. Ils peuvent être spécifié par les partenaires impliqués ou par une troisième partie (les meilleures pratiques du processus métiers). La définition des processus métiers partagés est sauvegardée dans le dictionnaire du broker. Le broker est responsable du routage des événements métiers au bon récepteur. L utilisation d un broker plutôt qu un modèle P2P est plus approprié car il apporte plus d avantages tels que: les partenaires interagissant sont découplés et faiblement connectés. Mais aussi, que les nouveaux partenaires peuvent intégrer leurs services durant l exécution d une instance de processus métier. Extension d ebxml EbXML est un standard d échange B2B du e-commerce a été étendu. Dans ce qui suit, nous présentons des extensions de ce standard. Extension du scénario d ebxml : Driouche et Al dans [54] ont étendu le scénario ebxml existant en y introduisant les paradigmes d agent, de service web ainsi que d ontologie de processus métier. Les services Web a été utilisés pour apporter plus de flexibilité, de simplicité, de neutralité et d'efficacité dans ce scénario mais aussi pour éliminer la difficulté de l'intégration due à l'hétérogénéité de modèle d échange. Les agents ont été utilisés pour garantir une sauvegarde du temps de recherche, pour négocier les paramètres d affaire et offrir une meilleure performance spécialement en présence des caractéristiques de mobilité qui résolvent le problème en relation avec le réseau tout en diminuant la consommation des ressources réseaux. Ils ont également proposé une architecture pour l intégration d'applications à deux niveaux: applicatif et collaboratif. - Applicatif : dans l'intégration d'a2a (Application-to-Application), une approche de mapping (mise en correspondance) a été proposée pour relier les ontologies d application. Cette intégration supporte plusieurs applications hétérogènes accédant à de multiples ontologies locales. Un composant, appelé mapper, génère une ontologie globale pour gérer l hétérogénéité de l information des entreprises basées sur les concepts de liaisons sémantique. - Collaboratif: dans l'intégration du B2B (Business-to-Business), un support de collaboration a été proposé entre les partenaires. Ce support se base sur un scénario étendu d EbXML et la construction d une ontologie de processus métiers. L intégration des processus métiers collaboratifs repose sur une ontologie de services. 40

Chapitre II: La collaboration des Processus Métiers Modèle de registre de collaboration sur le registre ebrim d ebxml : Une autre extension d ebxml a été proposée qui consiste en la définition d un modèle de registre de collaboration d affaire au-dessus du registre ebrim (E-Business Registry Information Model) d ebxml [65]. Cette solution a pour objectif de gérer les modèles de collaboration d affaire UMM (UN/CEFACT s Modeling Methodology) dans un registre. UMM permet de définir les processus métiers inter organisationnels. Il est également utilisé pour modéliser la chorégraphie et la validation des données échangées pour être agréée (accordée) entre partenaires. Les modèles UMM doivent être gérés dans un registre, car non seulement les partenaires métiers supportant le processus, peuvent les trouver et se lier à eux. Mais aussi, permettre la réutilisation d un modèle dans un autre modèle de processus inter-organisationnel. Un modèle UMM est définit à partir d une perspective globale. Les chorégraphies locales dérivent d un modèle global d UMM qui permet la configuration de chaque système partenaire. Une chorégraphie a le potentiel d accomplir un accord entre partenaires. Par conséquent, un modèle UMM de collaboration métier devient un type de «contrat» qui guide un partenariat d affaire. Un modèle de registre supportant les dépendances entre certains types d objets du registre est requis. Cependant, il peut exister des dépendances entre certains objets du registre, qui décrivent qu un objet du registre est exécuté. Ce dernier peut être une partie d un autre objet du registre, ou un objet du registre qui décrit les exigences d une chorégraphie, dont le flux est définit comme un profile UML. Autres : Utilisation des messages SOAP : Les changements des processus métiers peuvent être facilement implémentés par l échange des règles métiers. Ces règles métiers individuels peuvent être facilement réutilisées à travers différent processus métiers. Cet article [67] présente l idée de combiner le traitement de processus métiers (en utilisant les règles métiers) avec la capacité des web services d intégrer les ensembles de services hétérogènes et évolutifs. Dans le modèle d exécution proposé, l exécution des processus métiers est faite par le faire suivre d une enveloppe SOAP entre intermédiaires qui sont responsables du traitement d une ou plusieurs règles métiers. Les règles métiers à être traitées, sont représentées par les entrées d en-tête de l enveloppe SOAP. En définissant la séquence d exécution des entrées d en-tête, la séquence d exécution des règles métiers peut être représentée. Car les entrées peuvent utiliser n importe quel 41

Chapitre II: La collaboration des Processus Métiers namespace, les règles métiers peuvent être insérées comme des entrées dans l en-tête d une enveloppe SOAP, non seulement les processus linéaires peuvent être supportés par ce concept mais aussi en réseau avec une exécution alternative. L exécution distribuée des processus: Sadiq et Al ont définit dans [53] une approche Top Down pour la modélisation des processus intégrés et l exécution des processus distribués. Cette solution vise à faciliter l utilisation des modèles de processus pour un «monitoring» et une visualisation globale des modèles de processus distribués pour une exécution et un contrôle locale. Leur approche propose de modéliser les processus collaboratifs et d utiliser un algorithme de distribution pour extraire automatiquement les modèles de processus distribués sur la base de partitions spécifiées. Cette approche supporte la modélisation du processus global qui est intégrée dans un outil de modélisation de processus pour que ce processus puisse être analysé, vérifié, raffiné et amélioré. Une série d algorithme a été implémentée, afin de manipuler le modèle de processus intégré, pour dériver et aboutir à des modèles distribués avec les tâches de l expéditeur et du récepteur. Ainsi, des modèles distribués de processus sont générés automatiquement du modèle intégré. L exécution des processus métiers collaboratifs L approche proposée [57] pour l exécution des processus métiers collaboratifs, se base sur des indexes. Cette approche vise à améliorer la performance d exécution des processus métiers. Cette solution nécessite que chaque organisation maintienne un dictionnaire central de ses règles et de sa stratégie métier. Elle doit également se doter d un système pour contrôler la coordination des messages entre eux et de ses collaborateurs directs selon sa logique de processus. Afin que les vues du processus s exécutent. Cette approche a pour objectif que chaque partie puisse fonctionner d une manière autonome, contribuant dans l exécution du processus dès la réception du message pour indiquer que cette action particulière est requise sans une connaissance globale du processus. L exécution des processus métiers collaboratifs nécessite l état. Ce dernier est essentiel pour que chaque message soit interprété dans un certain contexte (ensemble de message reçus). Chaque message joue un rôle différent dans l exécution d un processus métier, et supporte des données spécifiques et des triggers (déclencheurs). Le composant le plus complexe dans l exécution des processus métiers collaboratifs est l évaluation des expressions qui décrivent le processus. L évaluation d expression peut prendre la valeur satisfaite ou partiellement satisfaite. Chaque expression peut requérir que de multiples messages soient reçus avant qu elle ne soit satisfaite, et que le contenu du message 42

Chapitre II: La collaboration des Processus Métiers soit utilisé dans la composition des messages sortants. Les messages doivent être enregistrés d une manière persistante ou temporaire, d où l utilisation des bases de données relationnelles ou XML. 10. Synthèse des solutions Dans ce qui suit, nous allons synthétiser les solutions présentées dans la section précédente et présenter leurs limites. 10.1 Classification des solutions Nous allons à présent faire une classification des solutions par type d approche adoptée, type d interaction, comment traiter la confidentialité des processus métiers. Cette classification est établie pour faciliter la synthèse. Approche de la collaboration La même approche pour la collaboration des processus métiers a été adoptée par [55], [61], [60], [63] et [64] qui consiste en la définition de la collaboration inter-entreprise sous forme d un processus métiers global qui représente le contrat, la distribution du processus métier global en des processus propres à chaque participant et enfin l exécution décentralisée des processus au niveau de chaque participant. La confidentialité des processus métiers La confidentialité des processus métiers a été traitée dans [64] en proposant un modèle pour organiser les processus métiers des organisations en des processus privés. Les processus métiers privés exposent les points d interactions pour que le processus partagé puisse s y lier. Ces processus sont encapsulés et exposés comme des services de processus métiers (abstraction des PB actuels) pour permettre une interaction dynamique et adaptable. Dans [55], les workflows intégrés peuvent être encapsulés ou non. Seulement, la confidentialité des processus métiers internes à l entreprise est préservée grâce aux interfaces de médiations développées. L interaction L interaction ou la chorégraphie peut être P2P ou centralisée. Dans [61], un gestionnaire de processus collaboratif a été développé pour supporter une gestion décentralisée et P2P du processus pour une collaboration inter-entreprise au niveau processus métiers avec des gestionnaires de processus collaboratif synchronisés par un protocole. Dans le comportement global proposé dans [63], les interactions sont multi-parties. La chorégraphie de processus métiers présentée dans [55], permet aux entreprises d établir des interactions P2P. 43

Chapitre II: La collaboration des Processus Métiers La solution dans [60] présente une chorégraphie centralisée à travers les organisations pour préserver l autonomie des processus métiers locaux. Le niveau de collaboration Dans [55] et [64], la collaboration a été définie au niveau de l activité, en définissant des points d interactions et en intégrant les workflows internes des entreprises. Les autres se basent essentiellement sur l intégration des processus métiers. Ces derniers peuvent être encapsulés ou non dans des web services afin d en obtenir des service processus métiers. L exécution du processus métier collaboratif L intérêt s est également porté sur l exécution des processus métiers collaboratifs comme dans [53] où une approche Top Down pour la modélisation du processus intégré et une exécution distribuée des processus. Ce modèle de processus intégré peut être utilisé pour un monitoring global et une visualisation et des modèles de processus distribués pour une exécution locale. Ou encore [57] l amélioration de l exécution du processus métier collaboratif par la définition d une approche qui se base sur l interrogation en incluant les index. Mais aussi dans [61] où l exécution d un processus collaboratif consiste en un ensemble d instances de processus pair, exécutées par les CPMs des parties participantes. Ces instances partagent la même définition du processus mais qui ont des propriétés additionnelles (par exemple le rôle: acheteur, vendeur) et peuvent avoir des données du processus privés et des sous-processus privés. 10.2 Les limites des solutions Ces solutions se basent sur les web services. Sachant que les web services n ont pas la notion d état (alors et qu ils interagissent avec des ressources à état) et n offrent pas de support pour la persistance de l état, pour la gestion de la durée de vie des ressources (processus métiers) et pour les notifications d événements [23] qui sont nécessaire pour les processus métiers ainsi que leur collaborations ([83] et [77]). A présent nous allons présenter comment ces solutions ont traité ces points importants : La persistance de l état a été géré avec des bases de données relationnelles ou XML dans [57] et dans un broker dans [56]. La notification a été gérée dans [57] avec des triggers pour l évaluation des expressions. Dans [61], la notification a été gérée par des messages de retours. 44

Chapitre II: La collaboration des Processus Métiers La gestion de la durée de vie des ressources n a pas été mentionnée. Nous pouvons ainsi voir que ces solutions n ont pas suffisamment traité ces points. Ainsi, une solution complète devra prendre en charge la persistance de l état, offrir un support pour la notification et la gestion de la durée de vie des ressources. Ces propriétés peuvent être retrouvées dans des spécifications apparues à la suite de la popularisation des Grid et de son succès dans la collaboration à grande échelle dans le domaine du E-Science. Ces spécifications ont été regroupées dans le Web Service Resource Framework (WSRF). Ce dernier sera détaillé dans le prochain chapitre. 11. Conclusion Ce chapitre s est porté sur les processus métiers, les langages permettant sa modélisation et sa description. Nous nous sommes également penché sur la définition et les solutions pour la collaboration des processus métiers. Ces solutions qui restent limitées, en ne traitant pas suffisamment des critères importants, tel que la persistance de l état dans les processus métiers, la notification pour la coordination entre participants et enfin la gestion des durées de vies des processus. Ces derniers, peuvent être retrouvés dans les Grids. Ainsi, le prochain chapitre va porter sur l utilisation des concepts grids avec les processus métiers. Le Grid qui englobe les organisations virtuelles et les grid services, a remporté un grand succès dans la collaboration des scientifiques dans le e-science [4] et que nous extrapoler et exploiter vers la collaboration inter-entreprise. 45

Chapitre III : Les Processus Métiers et les concepts des Grids Chapitre III : Les Processus Métiers et les concepts des Grids Résumé : Ce chapitre décrit les solutions qui combinent les processus métiers avec les concepts du Grid dans le domaine du e-commerce. Ce chapitre débutera par la définition des concepts du Grid à savoir les organisations virtuelles et les Grid services. Ensuite, nous décrirons les différentes solutions proposées, et finalement une synthèse de ses solutions. Le but de ce chapitre est de recenser les différentes solutions qui utilisent les concepts des Grids dans le e-commerce. 1. Introduction Les échanges inter entreprises sont une réalité à laquelle de nombreuses La collaboration dans le B2B est un concept très important dans le e-commerce. Cette collaboration est le centre d intérêt/intressent au plus haut point des chercheurs et des industriels, pour permettre une collaboration efficace et rentable. Le chapitre précédent s est porté entre autres sur les différentes solutions de collaboration. Auparavant, réaliser cette collaboration sur une plateforme unique, performante et simple à mettre en œuvre était un défi à part entière. Cependant, avec l apparition de la technologie Grid qui permet une collaboration à grande échelle et son succès dans le e-science, a ouvert une nouvelle orientation pour la collaboration B2B. Nous présentons dans ce chapitre en premier, la définition des concepts des Grid; les organisations virtuelles et les Grid services, ensuite les différentes solutions qui combinent les processus métiers avec les concepts des grids. 2. Définition du Grid Le terme Grid [1] est apparu en 1990 pour dénoter une infrastructure de calcul distribué proposé pour avancer les sciences et l ingénierie. Le Grid computing [2] est une forme de calcul distribué qui inclut, des applications, des données, du stockage, ou des ressources réseaux. Ces derniers sont coordonnés et partagés à travers des organisations dispersées géographiquement. (Pour plus de détails voir Annexe B). La definition a été donné par I. Foster et Al dans [1] The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly 46

Chapitre III : Les Processus Métiers et les concepts des Grids controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. Un résumé de la définition a été avancé dans [3] où le Grid a été définit comme étant un système qui coordonne les ressources qui ne sont pas sous un contrôle centralisé Le Grid Computing [8], ou calcul intensif distribué, peut se définir comme l utilisation simultanée des ressources de nombreux ordinateurs en réseau à la résolution d un même problème -généralement un problème qui nécessite une grande quantité de cycles de traitement ou l'accès à de gros volumes de données. Le Grid représente aussi un système qui utilise des protocoles et des interfaces ouverts et standards et délivre une qualité de service (QoS) non triviale [3]. 3. Les concepts du Grid L environnement du Grid a été développé pour répondre à un besoin en ressources. L utilisation des ressources (micro processeur, disque de stockage, programme, périphérique ect) est caractérisée par leur disponibilité en dehors du contexte du domaine local administratif. Cette approche d approvisionnement externe entraîne la création d un nouveau domaine administratif qui n est autre que l organisation virtuelle. Nous définissons dans la section suivante les organisations virtuelles et les grid services qui représentent les concepts du Grid. L Organisation Virtuelle Dans [1], I.Foster et Al ont introduit la notion d organisation virtuelle comme suit : Flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and resources. Cette notion d un ensemble d individus et/ou d institution définis par une forme de partage de règles est appelée organisation virtuelle (OV). Les organisations virtuelles permettent à des organisations individuelles ou/et en groupe dispersés de partager les ressources d une façon contrôlée de telle sorte à ce que ces membres peuvent collaborer pour atteindre des objectifs communs. Quelques exemples concrets des organisations virtuelles sont cités dans [1] tels que : L application des services fournisseurs (Service Provider SP) ; Le stockage des services fournisseurs ; Les consultants engagés par un constructeur d automobiles pour exécuter un scénario d évaluation durant la planification d une nouvelle usine ; L utilisation des systèmes de bases de données et des systèmes de simulations par une équipe de gestion de crise pour planifier une réponse à une situation d urgence 47

Chapitre III : Les Processus Métiers et les concepts des Grids Les Grid Services L infrastructure du Grid supporte la création d environnement de calcul intégré dans lequel des organisations virtuelles peuvent partager des données, ressource etc, pour atteindre des objectifs communs. Cependant, l émergence des Web Services fournit un cadre de travail pour l interaction d application à application. Pour cela, la communauté Grid, a voulut aligner les technologies du Grid avec celles des Web Services en donnant naissance à des normes OGSA 27, l OGSI 28 et WSRF 29. Ces derniers, permettent d intégrer, de définir et de spécifier les services et les ressources à travers des communautés dynamiques. La présentation des Grid Services et de ces concepts fera l objet de la section suivante. Définition des Grid Services Un Grid service [15] est potentiellement un Web Service transitoire basé sur les protocoles du Grid. Ces protocoles sont exprimés en utilisant le WSDL. Chaque Grid Service est un Web Service mais le contraire n est pas vrai. Contrairement aux Web Services qui n ont pas de notion d état. Cette notion existe dans les grid services, elle est très importante car elle augmente la fiabilité et permet de redémarrer suite à un échec avec une considération de l historique des interactions précédentes [16]. Dans les Grids, le modèle OGSA supporte la création et la destruction dynamiques des instances de service transitoires (transient). Un Grid Service ([14] et [15]) est un Web Service qui fournit un ensemble d interfaces bien définies et suit des conventions spécifiques. Les interfaces présentent: la découverte, la création dynamique de service, la gestion de la durée de vie et la notification. Le terme «Grid Service instance» fait référence à une instanciation particulière du Grid Service. Cette notion d instance de service peut être une requête pour un data Warehouse, une allocation de ressources réseaux, ou encore une session d un forum de discussion. Une instance de service est créée par un service de fabrique, qui lui, est généralement un Grid Service persistant. Cette instance est alors associée à une durée de vie et peut être détruite, soit de façon explicite, soit au terme de sa durée de vie (soft-state lifetime management) [22]. La définition de l instance dans l OGSI et le WSRF est différente. Les Grid Services sont caractérisés par les capacités qu ils offrent. Un Grid Service implémente plusieurs interfaces où chaque interface définie un ensemble d opérations qui sont 27 OGSA: Open Grid Service Architecture 28 OGSI: Open Grid Service Infrastructure 29 WSRF: Web Service Resource Framework. 48

Chapitre III : Les Processus Métiers et les concepts des Grids invoqués en échangeant une séquence de message définies. Les interfaces Grid Services correspondent au PortType dans le WSDL [24]. Le Grid Service ou web service à état peut maintenir un état interne pour la durée de vie du service. L existence de l état distingue une instance d un service d un autre Service qui fournit la même interface [24]. Cet état peut être par exemple une donnée dans un ordre d achat, les agréments de service représentant la disponibilité des ressources ou le chargement courant dans un ordinateur, ou encore la température d un disque dur. Deux approches existent pour modéliser et manipuler l état: l OGSI et le WSRF [68]. Exemple de composants systèmes qui peuvent être modélisés comme des ressources à état : les fichiers dans un système de fichier, les lignes dans une base de données relationnelles [69]. La notion d état de service (stateful web service) [14] a été introduite pour : - Permettre de définir des approches de création, d appellation (naming) et de gestion de la durée de vie des instances de services ; - Déclarer et découvrir les données de services ; - Notifier de façon asynchrone le changement d état du service ; - Pour un support commun de l invocation du service ; - Représenter et gérer les collections d instances de services. Les principes des Grid Services Le Global Grid Forum (GGF) a définit les normes OGSA et WSRF (évolution de l OGSI, voir annexe B) pour les grid services qui seront détaillées dans les sections suivantes. Figure 13: Relation entre OGSA, OGSI et WSRF 30. 30 Python WSRF Programmers' Tutorial. http://dsd.lbl.gov/gtg/projects/pygridware/doc/tutorial/html/c182.html 49

Chapitre III : Les Processus Métiers et les concepts des Grids Les principes de l Open Grid Service Architecture (OGSA) L alignement des deux technologies, Web Services et Grid Computing est appelé Open Grid Service Architecture (OGSA). Le terme «Open» est utilisé pour communiquer l extensibilité, la neutralité du vendeur, et la validation d une communauté de standardisation de processus [24]. L OGSA permet de définir les bases des Grids, et de proposer un «framework» à travers lequel tous les services adhèrent à des interfaces et comportements de Grid services. Ces derniers sont définis en termes d interface WSDL, de conventions, de mécanismes pour la création, et de la composition des systèmes distribués sophistiqués [15]. La définition de l OGSA est conduite par un ensemble de conditions fonctionnelles et nonfonctionnelles qui sont informées par les cas d utilisations. Citons comme exemple: le centre de données commerciales, Grid Workflow [23]. L OGSA fournit un Framework [15] qui supporte : 1. La création d instance : le Grid Service Factory peut être interrogé pour créer une nouvelle instance de service transitoire et fiable. Il fournit un mécanisme pour une identification individuelle de ces instances en associant quelques informations d état avec chaque instance de service. Figure 14: Création d'une instance de service [13] 2. La gestion de la durée de vie : la durée de vie de ces instances de service peut être négociée avec le Grid Service Factory au moment de la création de l instance. 3. L enregistrement et la découverte : permet l enregistrement et la découverte d instances de services transitoires. Il fournit un mécanisme d interrogation efficace pour le client en utilisant l opération Find Service Data du Grid Service sur les métadonnées contenues dans ce registre. Il fournit aussi un document Web Service Inspection qui contient les détails concernant tous les services contenus dans ce registre. Un Grid Service peut s enregistrer dans WS-Inspection (Web Service 50

Chapitre III : Les Processus Métiers et les concepts des Grids Inspection 31 ) ou encore dans un registre UDDI. Ce dernier permet la publication et la recherche de partenaires métiers et de leurs Grid Services. Il existe deux types de registre : un registre UDDI privé et un registre UDDI public. Figure 15: Publication de Grid Services [45] 4. La notification : elle établit un modèle de publication/souscription d un mécanisme de notification entre le fournisseur de service et le demandeur de service. Ceci en fournissant un style de communication asynchrone du peer-to-peer (P2P). Grid Service instance Souscrire Client Client Service Data Element Délivrer notification Client Client Figure 16: Le mécanisme de notification [13] 5. La sécurité : l administration sûre nécessite un contrôle d accès aux services à travers des protocoles de sécurité robuste et une relation avec les politiques de sécurité fournies Par exemple, l obtention des programmes d application et le déploiement dans un système Grid peut nécessiter l authentification et l autorisation. Le partage des ressources par les utilisateurs, peut demander quelques mécanismes d isolation et de sécurité qui peuvent être déployés pour protéger les systèmes Grid pendant le partage fiable des ressources à travers les domaines. Les besoins en sécurité incluent : L authentification et l autorisation: les mécanismes d authentification sont requis pour que l identité des individus et services puisse être établie. Le service fournisseur doit implémenter des mécanismes d autorisation pour renforcer chaque service pouvant être utilisé. 31 IBM. Web Service Inspection Language http://www-128.ibm.com/developerworks/library/specification/ws-wsilspec/ 51

Chapitre III : Les Processus Métiers et les concepts des Grids L Infrastructure de sécurité multiples : les opérations distribuées impliquent un besoin d intégration et d interopérabilité avec des infrastructures de sécurité multiples. L OGSA a besoin d intégrer et d intéropérer avec des architectures et modèles de sécurités existantes Les solutions de sécurité de périmètre : des ressources peuvent être accessible à travers les frontières organisationnelles. L OGSA requiert des mécanismes et standards de sécurité qui peuvent être déployés pour protéger les organisations sans compromettre les mécanismes locaux de la sécurité telle que la politique Firewall et la politique de détection d intrusions. La délégation : mécanisme qui prend en considération la délégation des droits d accès à partir d un demandeur de service à un fournisseur de service requis. Cependant, le risque d abus de droits existe. 6- L interopérabilité : l environnement Grid tend à être hétérogène, distribué comportant des services et des environnements d accueil divers, etc. Il peut évoluer d une façon qui n a pas été prévue initialement. L OGSA doit permettre l interopérabilité entre divers services et ressources, hétérogènes et distribués. Il doit aussi bien réduire la complexité d administration des systèmes hétérogènes. Le besoin de supporter les systèmes hétérogènes exige : a. La virtualisation des ressources pour réduire la complexité de la gestion des systèmes hétérogènes et pour supporter diverses ressources d une façon unifiée. b. Capacité de gestion commune. Un ensemble minimal de capacité de gestion commune est requise. Pour permettre un mécanisme d administration des systèmes hétérogènes et une gestion uniforme et consistante des ressources c. Le partage de ressource à travers les organisations: le Grid n est pas un système monolithique mais peut souvent être composé de ressources propriétaires et contrôlés par des organisations diverses. 7- L optimisation : l optimisation se réfère aux techniques utilisées a. Pour allouer des ressources effectives b. Pour rencontrer les besoins des consommateurs et fournisseurs. L optimisation s applique aussi bien au consommateur qu au fournisseur des ressources et de services. Le WS-Resource Framework (WSRF) En juillet 2003, l OGSI (Annexe B) définit un ensemble de convention et d extension pour l utilisation du langage de définition des Web Services (WSDL) et le schéma XML. Ces 52

Chapitre III : Les Processus Métiers et les concepts des Grids derniers permettent la description d un Web Service à Etat (Stateful Web Service) ou encore d un Grid Service. Cependant, l OGSI a été critiqué par la communauté des web Services pour différentes raisons [16]: - En avançant que l OGSI modélisait une ressource à état comme un web service qui encapsule l état de cette ressource alors que les «web services n avaient ni des états ni des instances», - L OGSI comportait beaucoup de spécifications sans séparation de fonction pour une adoption incrémentale, - Ou encore que cette norme ne travaillait pas avec les web services existant et leurs outils, - Et finalement que cette spécification ne supportait pas le WSDL 2.0 32 (WSDL2.0 recommandation en juin 2007). D où la nouvelle spécification à savoir le Web Service Resource Framework (WSRF) qui a été proposé en janvier 2004, comme une évolution de l OGSI. L objectif du WSRF est l exploitation de nouveaux standards de Web Services, spécialement WS-Addressing 33. Par ailleurs, le WSRF retient essentiellement toutes les capacités fonctionnelles présentes dans l OGSI, alors que quelques changements de syntaxe et aussi l adoption d une terminologie différente dans sa présentation ont été remarqués [19]. Le WSRF définit la création, l adressage, l inspection et la gestion de la durée de vie des ressources à état. Il fournit également, la définition pour exprimer l état comme des ressources à état et codifie la relation entre les web services et les ressources à état en terme de «implied resource pattern». Ce dernier est un ensemble de conventions sur les technologies de web services en particulier le WSDL et le WS- Addressing. La composition d une ressource à état et un web service qui participent dans un «Implied Resource Pattern» est appelé WS-Resource. Le WS-Resource est la composition de ressources à état et de Web Service qui participe à la construction d un modèle de ressources implicites (Implied Resource Pattern)[16]. WS-Resource [85] Le WS-Resource représente l état dans un contexte Service Web (SW). Les WS- Resources ne sont pas liés à un seul WS, de ce fait, de multiple WS peuvent gérer et 32 Nouvelle recommandation le 26 Juin 2007 par le W3C. http://www.w3.org/tr/wsdl20/ 33 http://www.w3.org/2006/04/wsaddressing-pressrelease.html.fr 53

Chapitre III : Les Processus Métiers et les concepts des Grids surveiller la même instance WS-Resource avec une logique métier différente et à partir d une perspective différente. L état a des composants atomiques appelés les éléments Resources Properties, qui peuvent être mis à jour et interrogés. Ces derniers, sont rassemblés dans un document XML qui peut être interrogé par les applications clients en utilisant XPath 34 ou n importe quel autre langage d interrogation. Le WSRF supporte une insertion et une suppression dynamique d éléments de propriétés de ressources d un WS- Resource au moment de l exécution. L identité unique de la ressource est appelée Endpoint Reference (EPR) qui adhère au WS-Addressing. Implied Resource Pattern : Le terme Implied ou implicite est utilisé car l identité de la ressource n est pas une partie du message requête, mais qui est plutôt spécifié en utilisant les composants des propriétés des références du WS-Addressing. Le terme Pattern indique que la relation entre web service et les ressources à état est codifiée en utilisant XML, WSDL et WS-Addressing. Le WS-Addresing définit la relation entre le WS et les ressources à état qui est le centre du WSRF. Les spécifications WSRF recommandent l utilisation du pattern Factory/Instance i.e Implied Resource Pattern. [69] En résumé le WSRF [83]: - Spécifie des aspects divers reliés aux web services à état. - Définit un modèle d échange de message sur la création, l adressage et la destruction des web services à état. - Définit les conventions dans un contexte de standards de web services établis pour la gestion de l état pour que les applications puissent partager d une manière fiable les changements d information, la découverte, l inspection et l interaction avec des ressources à état dans une manière standard et interopérable. Les spécifications du WSRF : Le WSRF comporte cinq spécifications : 1. WS-ResourceProperties Le WS-ResourceProperties décrit l association des ressources à état et les Services Web pour produire les WS-Resource, et comment les éléments des propriétés publiquement visibles d un WS-Resource sont extraits, modifiés et supprimés. 2. WS-ResourceLifeTime : la durée de vie d un WS-Ressource est définit comme la période entre les instanciations et ses destructions. Il permet au demandeur de détruire un WS-Resource soit immédiatement soit à un point futur donné dans le temps. Les instances 34 W3C. XML Path Language (XPath) http://www.w3.org/tr/xpath 54

Chapitre III : Les Processus Métiers et les concepts des Grids d une ressource ont une certaine durée de vie, qui peuvent être renouvelées avant qu elles n expirent comme spécifié dans la spécification WS-ResourceLifeTime. Ils peuvent aussi être détruit prématurément comme nécessaire par l application. 3. WS-ServiceGroup [87] : le WS-ServiceGroup fournit une description d une WS- Resource d objectif général qui agrége l information de multiples WS-Resource ou WS pour un domaine spécifique. L information agrégée peut être utilisée comme un dictionnaire dans lequel les résumés descriptifs des WS-Resources individuels et des Web Services peuvent être interrogés pour identifier les entrées utiles. Le WS-ServiceGroup lui-même est un WS à état qui est une collection d autres WS (ou WS-Resource) et l information qui s y rapporte. L adhésion dans le ServiceGroup est flexible et peut être définit par la spécification à travers le ServiceGroupRegistration. Les détails de chaque membre dans le ServiceGroup sont sous la forme de WS-ResourceProperties ; qui traduit les EPRs et les contenus d un membre. L adhésion dans le groupe peut également être limitée, contrôlée à travers des stratégies spécifiques pour permettre aux demandeurs de former des interrogations significatives sur les contenus des WS-ServiceGroup. 4. WS-BaseFault : décrit une base de type par défaut pour les erreurs de reporting. Car, une application typique de Web Service utilise souvent des interfaces définit par d autre. La gestion des erreurs et des exceptions dans de telle application est difficile quand chaque interface utilise une convention différente pour la représentation d une information commune dans des messages d exceptions. Les messages d erreurs et d exception des WS déclarés d une manière commune améliore le support pour la détermination du problème et la gestion des exceptions. 5. WS-RenewableReferences : Instancie une référence de WS-Addressing avec l'information nécessaire pour récupérer une adresse quand l'adresse en possession est invalide. Il annote la référence du point final du WS-Addressing avec des informations requises pour extraire une nouvelle référence du point final quand la référence courante devient invalide. (En cours de définition). En plus de des ces quatre spécifications à savoir le WS-ResourceProperties, le WS- ResourceLifeTime, le WS-ServiceGroup et le WS-BaseFault, Le WSRF se réfère également à deux autres spécifications WS-Notification et WS-Addressing. A. Le Web Service Addressing : 55

Chapitre III : Les Processus Métiers et les concepts des Grids En mai 2006, le W3C 35 recommande officiellement l utilisation du Web Services Addressing (WS-Adressing) [26] pour l'adressage de Web Services. Le WS-Addressing définit un standard pour incorporer l information d adressage du message dans SOAP. Ce dernier ne fournit pas une façon standard pour spécifier la destination du message, comment retourner une réponse ou bien où reporté une erreur. WS-Addressing introduit deux nouveaux concepts au vocabulaire des web services : Endpoint Reference et Message Addressing. Endpoint Reference (EPR) ou bien les références des points d entrée. Une référence de point d entrée est une structure de donnée définit pour encapsuler toutes les informations nécessaires pour étendre un point d entrée d un service à l exécution. <wsa:endpointreference xmlns:wsa="..." xmlns:example="..."> <wsa:address>http://example.com/contact</wsa:address> <wsa:referenceproperties> <example:contacttype>family</example:contacttype > </wsa:referenceproperties> <wsa:referenceparameters> <example:detail>mobile</example: detail > </wsa:referenceparameters> </wsa:endpointreference> Figure 17: Exemple d'un EPR [83]. Message Addressing (Les propriétés d adressage du message): Le WS-Addressing introduit un ensemble de message d en-tête fournissant l information concernant un message par l incorporation de la livraison, répondre à, et traitement des exceptions et des erreurs dans l enveloppe SOAP qui sont nécessaire pour supporter une interaction riche et bidirectionnelle. <S:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2004/12/addressing"> <S:Header> <wsa:messageid> http://... </wsa:messageid> <wsa:replyto> <wsa:address>http://client.application</wsa:address> </wsa:replyto> <wsa:faultto> <wsa:address>http://logging.application</wsa:address> </wsa:faultto> <wsa:to>http://service.to.invoke</wsa:to> <wsa:action>http:// method.to.invoke</wsa:action> </S:Header> <S:Body> <!-- The message body of the SOAP request appears here --> </S:Body> </S:Envelope> Figure 18: Message SOAP avec WS-Addressing [83] B. WS- Notification 36 35 http://www.w3.org/ 36 Web Services Notification (WS-Notification) [En Ligne] http://www.ibm.com/developerworks/library/ws-resource/ws-notification.pdf. 56

Chapitre III : Les Processus Métiers et les concepts des Grids L EPR fournit une façon de pointer les web services ainsi que la ressource à état dans un élément pratique. Le pattern de notification conduit par l événement ou basé sur la notification est communément un pattern utilisé pour les communications inter-objets. Ce pattern de notification peut être étendu sous différentes façons pour rencontrer les exigences des applications. Conduit par les événements, ou basés sur les notifications, le pattern d interaction est un pattern communément utilisé dans des extensions variées; les systèmes de «publication/souscription» fournis par les vendeurs de médiateurs orientés messages; support pour un pattern «observable/observateur» dans les langages de programmation. Dû à la nature sans état des service web; le paradigme Web Service n a aucune notion de notification ; ce qui limite considérablement l application des web services pour le développement d application compliquée. WSRF définit les conventions pour la gestion de l état pour que les applications puissent partager d une manière fiable le changement d information, la découverte, l inspection et l interaction avec les ressources à état d une façon standard et intéropérable ; apportant un pattern d interaction qui se base sur la notification dans le domaine des Web services. A new notification has arrived The Crop Quantity which you will purchase from a seller is 10.0Kg A new notification has arrived Amount Offered by you per Kg is:rs70.0 A new notification has arrived Amount spent by you in current purchase is Rs700.0 Figure 19: Exemple de notification avec WS-Notification [83]. WS-Notification comprend trois spécifications séparées : WS-BaseDefault, WS- BrokeredNotification, WS-Topic, seulement leurs utilisation dans WSRF reste très limitée [88]. 4. Les Solutions combinant les Processus Métiers avec les concepts des Grids L apparition et le succès du Grid a changé la vision des industriels et des chercheurs sur la collaboration et le partage des ressources hétérogènes et distribuées. Le B2B présente un domaine d application très attrayant pour les concepts du Grid. La collaboration des processus métiers est une réalité du B2B, dont l automatisation réduira le coût et le temps des transactions entre partenaires. Ainsi, nous allons introduire les différentes solutions qui combinent les concepts du Grid avec les processus métiers. 57

Chapitre III : Les Processus Métiers et les concepts des Grids 4.1 Pourquoi combiner les Processus Métiers avec les concepts des Grids? Le processus B2B est un processus métier complexe qui contient un ensemble de services, d état et de gestion de transaction et inclut la notification de plusieurs événements qui apparaissent durant l exécution d un processus. Les processus métiers sont conduits par des événements et chaque processus devrait être capable de manipuler la nature dynamique d une entreprise et des partenaires affaires tel que les changements dans les stratégies, les politiques et la gestion des exceptions [49]. La tendance de réduire de plus en plus le cycle métier a stimulé la demande pour des technologies qui peuvent être utilisées pour construire et faire fonctionner les systèmes d information d une manière simple et sécurisée, mais également de charger les fonctions du système et de gérer leur performances facilement [79]. Les processus métiers nécessitent un support pour la persistance de l état, le monitoring, l hétérogénéité, la gestion des transactions et les notifications d événements ([83] et [77]). L architecture des web services permet l hétérogénéité mais manque d un support pour l état, l événement et la notification, et la gestion du cycle de vie des ressources [23]. La conception du Grid assure l interopérabilité des plateformes, la découverte, la réutilisation et l intégration des systèmes dans un contexte hétérogène. Cette dernière représente l exigence clé du processus métier [83]. Nombreux industriels ont lancé des solutions e-business qui se basent sur la technologie grid, tel que IBM, SUN, HP, et Oracle [75]. Et ceux qui ont lancé des projets tel que Fujitsu LTD, Hitashi, Nec Corp, LTD pour le projet Grid Business [79]. Les concepts du grid à savoir les organisations virtuelles et les grids services ont été intégrés dans la collaboration des processus métiers: Les organisations virtuelles Elles sont utilisées pour modéliser les équipes de concepteurs de produits et les exécutifs métiers de la compagnie. La virtualisation des organisations business permet un accès consistant aux systèmes métiers et aux ressources gérées à travers les systèmes métiers hétérogènes. [76] L intégration des Grid services : Le concept du Grid a été introduit dans le processus métier en donnant lieu au «Business Process Grid» [41] : 58

Chapitre III : Les Processus Métiers et les concepts des Grids 1. Pour protéger l investissement existant de l entreprise en encapsulant les systèmes propriétaires et les systèmes métiers (Les systèmes métiers peuvent être un SCM 37, CRM 38, ERP 39 ou encore un BPM) de l entreprise pour une nouvelle intégration [75]. 2. Pour encapsuler et virtualiser les applications des entreprises, afin d être intégré avec la méthode d intégration de service. ([75], [76]). 3. Pour couvrir l approvisionnement et l Outsourcing (externalisation) des processus métiers, l intégration, la collaboration, le monitoring et une infrastructure de gestion des processus dynamiques [83]. 4. Car ils étendent les services web, les rendent des services à état, transitoire, offrent un support de notification. Ces dernières sont importantes pour les processus métiers [83]. 4.2 Les solutions combinant les Processus Métiers avec les concepts du Grid Cette section comporte les différentes solutions proposées dans le e-commerce ou encore le e-business, qui se basent sur les concepts du Grids (Grid services et organisations virtuelles). A. Solution de Lin et Al, plateforme de collaboration e-business basée sur les grid services [75] Lin et Al dans [75] ont développé une plateforme de collaboration e-business basée sur les grid services. Cette plateforme a été implémenté dans le système du groupe Zhejiang FuLiDa de textile (Zhejiang FuLiDa Textile Group), dont les résultats ont prouvé que le système était efficace et fonctionnel. Cette plateforme a permis de réduire le coût métier de 30%, le temps de traitement des bons de 15%, la réduction du cycle de développement des produits de 20% tout en réduisant le temps du stock qui passe de 21 jours à 10 jours. Les auteurs de cet articles ont utilisé les grid services pour encapsuler et virtualiser les applications des entreprises. Cette architecture peut réaliser le partage d information, une planification, une conception et un commerce collaboratif. Cette plateforme n est pas seulement un système commercial B2B ou B2C 40, mais un système intégré avec une multitude de fonction et de participant. C est une architecture d intégration et de collaboration métier. L intégration étant la base de la collaboration parmi les partenaires et la collaboration étant le but de l intégration. L architecture de la plateforme comprend quatre type 37 SCM: Supply Chain Management. 38 CRM: Customer Relationship Management. 39 ERP: Enterprise Resource Planning. 40 B2C: Business to Consumer. 59

Chapitre III : Les Processus Métiers et les concepts des Grids d intégration et de collaboration: une plateforme e-business avec les systèmes internes de l entreprise, une plateforme e-business avec d autre entreprise, une plateforme e-business avec les départements gouvernementaux et sociaux et une plateforme e-business avec les clients. Le système présente quatre couches comme illustré dans la figure ci-dessous : Figure 20: Les quatre couches du système [75]. 1. La couche de base est la couche de ressource de service OGSA, elle représente la base des ressources de la plateforme collaborative e-business. 2. La seconde couche, est la couche application, qui inclut tous les services collaboratifs du e-business (CRM, SCM..) et les services d application d autres entreprises. Les services d application d entreprise, service de communication de partenaires, les services du département social et les services d interaction du client sont également intégrés dans la plateforme. 3. La troisième couche est la couche de gestion des flux de services qui comporte trois parties: la description du flux de service basée sur XML, un moteur de flux de services et un registre d entreprise UDDI. Le flux de service est décrit en XML. Le moteur invoque les services décrits en un fichier de service de flux. Tous les grid services sont enregistrés au niveau du registre UDDI de l entreprise. Le moteur peut facilement trouver le grid service propre pour compléter le processus collaboratif du e-business. 4. La dernière couche est l interface utilisateur qui fournit des interfaces variables pour les utilisateurs. Une notion très importante au niveau des applications de l entreprise a été également intégrée à savoir la sécurité. Cette dernière a été intégrée en se basant sur les protocoles de sécurité 60

Chapitre III : Les Processus Métiers et les concepts des Grids dans les Grids. Le Single-Sign-On a également était introduit, en intégrant une solution locale de sécurité au système global collaboratif avec un mécanisme de mapping de rôle. B. Solution de Jun-Jang Jen et Al : [76] l architecture d un framework basé sur les Grid pour une méta-gestion des processus métiers La plateforme proposée appelé BPMM «Business Process Meta-Management», comprend les processus métiers à base de grid services (Business Process Grid Services : BPGS). Ces derniers sont utilisés pour fournir un accès uniforme, robuste et scalable à des processus métiers hautement diversifiés et à des systèmes d affaires. Les systèmes BPMM ont été proposé afin de palier aux problèmes de l abstraction des ressources de processus métiers et la définition de la qualité de service des processus métiers. Cette proposition adresse des défis tel que l autonomie des processus métiers, le problème des systèmes hétérogènes des processus métiers, l extensibilité de la stratégie des processus métier. L architecture du BPMM comprend : Figure 21: L'architecture du BPMM [76]. - Un gestionnaire de processus métiers: ce gestionnaire est un grid service. Il est responsable de l ordonnancement des activités à s exécuter et des liaisons des processus métiers appropriés. L ordonnancement de l exécution des activités peut venir du script d un processus métier tel qu un modèle de workflow ou des règles métiers. - Des courtiers de processus métiers: responsables pour la prise des interrogations à un haut niveau des processus métiers et de les transformer en des interrogations plus 61

Chapitre III : Les Processus Métiers et les concepts des Grids concrètes au plus bas niveau comme des systèmes métiers et des systèmes d exploitation. Ils reçoivent les requêtes des processus métiers à partir d une organisation virtuelle, les traduit en des interrogations BPGS concrètes. Ainsi, les interrogations sont livrées aux gestionnaires de processus métiers appropriés pour les liens de processus métiers. - Un analyseur de processus métiers: fournit les services qui exécutent l analyse comportementale sur les processus métiers et les systèmes métiers qui sont gérés dans l environnement BPMM. Par exemple: le Data Mining et la découverte des connaissances. - Des navigateurs de processus métiers : sont utilisés pour la découverte des gestionnaires de processus métiers et la localisation des ressources de processus métiers disponible qui rencontrent la validation affaires. Les BPGS simplifient la virtualisation à travers l encapsulation des implémentations diverses derrière une interface commune. Cette virtualisation permet aussi les mappings de multiples instances logiques des processus métiers en les mêmes processus métiers physiques qui sont englobés dans des systèmes métiers différents. La virtualisation aide à composer les services à partir d une variété de processus métier et de systèmes métiers sans voir comment ses services sont implémentés et configurés dans leurs systèmes métiers respectifs. - Les caractéristiques des BPGS (Business Process Grid Services) : BPGS virtualise les processus métiers, les ressources gérées et les systèmes métiers. BPGS peut maintenir un état interne pour sa durée de vie ; qui est très importante pour une longue exécution des BP. Au cours de l exécution, BPGS est souvent instancié en une nouvelle instance de services transitoires avec l état d un BP spécifique. Quand l état n est plus requis le PBGS peut être détruit. BPGS se situe au dessus des grid services dans le framework proposé. La description des BPGS s est faite à travers la norme OGSI 41. C. Solution de Zakir Laliwala et Al [77] Architecture orientée grid service sémantique basée pour les processus métiers : L architecture proposée vise à automatiser des processus métiers. Pour cela, Zakir Laliwala et Al ont utilisé la sémantique (ontologie, règles sémantiques) et les Grid services. 41 OGSI: Open Grid Service Infrastructure. 62

Chapitre III : Les Processus Métiers et les concepts des Grids La sémantique est la seule solution pour trouver de l information compréhensible et de l intégrer avec les informations. L approche sémantique aide dans la recherche, la découverte, la sélection, la composition et l intégration des web services mais également l automatisation de l invocation, la composition et l exécution des services. Pour cela ils ont utilisé l ontologie (OWL, RDF) et les règles sémantiques (SWRL: Semantic Web Rule Language). La sémantique est utilisée pour fournir un vocabulaire commun, des connaissances, des contraintes et un support pour l automatisation. Les grid services ont été utilisés pour décrire les web services à état, les transactions, la notification et le passage à l échelle. L architecture proposée a été appliquée à un cas réel en Inde dans le domaine du marketing dans le domaine de l agriculture. Elle a permis une intégration significative et sans coupure de l information, une interopérabilité des services distribués et hétérogènes, une composition de service dynamique basée sur les événements, une exécution et un monitoring des services. Figure 22: L architecture proposée [77]. Cette architecture comporte : - Les services d information qui jouent le rôle d un médiateur entre les services métiers et les clients. Ils fournissent l information sur les exigences et les préférences des utilisateurs et la gestion des comptes utilisateurs. Il guide l exécution du workflow en interagissant avec l ontologie, les règles et les connaissances d affaire. - Les services métiers ou business services : ce sont les services qui prennent part des processus métiers qui sont cruciaux et implémentés comme des grid services. Ces services utilisent le WSRF. Ils requièrent un support pour la notification d état et la gestion des transactions - Les Grid services : plusieurs grid services sont utilisés, tel qu un grid service pour la gestion de ressource, la sécurité, la gestion de job 63

Chapitre III : Les Processus Métiers et les concepts des Grids - Le Server d ontologie : l ontologie fournit un support à deux niveaux: un pour fournir un vocabulaire commun du domaine de l agriculture et un autre pour fournir la connaissance concernant les différents services. L ontologie est développée pour couvrir les différents aspects du sujet. - Le Moteur de règles: contient un ensemble de règles. Il augmente la fonctionnalité du web sémantique et donne une connaissance du comportement. Il fournit le flux, les contraintes et les contrôles du comportement d un processus métier. - Le Web service du client mobile pour supporter la connectivité mobile et rurale. D. Solution de Asif Akram et Al [83] Le système proposé couvre une application dans le domaine de l agriculture en Inde (Agricultural Marketing Process). Le système proposé comporte: - Les gestionnaires du Grid (Grid Managers) Ce service est une implémentation du Implied Resource Pattern. Il initie les différents types de ressources (vendeur, acheteur, produits agricoles et le marché) selon la requête du client hébergée par les différents noeuds du grid. Le gestionnaire du grid orchestre les différents composants du système d une manière prédéfinie pour le bon fonctionnement de l application. Le gestionnaire du grid est le premier point de contact avec le système. - Les noeuds du Grid (Grid Nodes) : les noeuds du grid représentent un environnement qui héberge les différents Web Services à Etat. Les services hébergés sur ces différents noeuds sont utilisés dans différentes combinaisons pour capturer les exigences de l application. Chaque WS-Resource initialisée a un EPR qui lui est attaché. L EPR identifie la ressource et l URL de l instance du service géré. Ces nœuds sont géographiquement dispersés à travers les différentes entreprises. - Le registre Grid (Grid Registry) : le registre grid est un service spécial qui se base sur la spécification WS-ServiceGroup. Ce registre garde trace des différentes ressources initialisées durant l application. Le client grid (acheteur ou vendeur) peut mettre à jour ou interroger le registre grid pour rechercher les ressources appropriées. - Le client Grid (Grid Client) le client grid est une application externe qui nécessite l initialisation des ressources ou l interaction avec les ressources existantes pour les interroger, les détruire ou les modifier. Le client adhère avec la spécification WS-Adressing pour travailler avec le WS-Resource et les services correspondant à travers leurs EPRs. Dans le cas étudié, le client grid (peut avoir trois rôles : acheteur, vendeur et administrateur) instancie les servicrs du marché pour le commerce. 64

Chapitre III : Les Processus Métiers et les concepts des Grids L interaction entre ces composants Nous allons présenter dans ce qui suit, le diagramme de séquence Service du vendeur et ses interactions avec les différents composants. Figure 23: Diagramme de séquence du service vendeur. La première interaction du vendeur avec le système résulte de la création d un nouveau WS- Resource vendeur. Cette ressource devra capturer tous les détails du vendeur spécifique et les utiliser dans les interactions futures avec ce vendeur. La figure 17 nous démontre la séquence d événement qui permet l enregistrement de l acheteur avec son intention d acheter les produits requis dans le marché. 1. Le commerce pour un vendeur commence par l expression de son intention de vendre un produit agricole disponible en incluant son libellé, la quantité et le marché de la région avec le GridManagerClient. 2. Le GridManagerClient envoi une requête au GridManagerService qui créé une instance du SellerResource. 3. Une fois la ressource du vendeur créée, elle est enregistrée avec le DefaultIndexService (Grid Registry). 4. Le GridManager retourne l EPR de la ressource du vendeur (SellerResource) nouvellement créée au GridManagerClient. 5. Le GridManagerClient utilise l EPR pour invoquer les différentes opérations pour mettre à jour la ressource nouvellement créée. Pour le service acheteur, la procédure est identique à celle du vendeur. A présent, nous allons voir le diagramme de séquence du marché pour un commerce. 65

Chapitre III : Les Processus Métiers et les concepts des Grids Figure 24 : Diagramme de séquence du marché pour un commerce directe. La figure 18 démontre les interactions entre vendeur et acheteur durant une transaction dans un mode directe. Une fois le MarketResource instancié à travers le GridManagerClient, le marché commence ses opérations 1. Le GridManagerClient invoque le GridManagerService pour une créer une nouvelle instance de la ressource du marché (MarketResource). Le GridManagerService déclenche la création d une nouvelle ressource MarketResource en utilisant l instance du marché et retourne un EPR au GridManagerClient. 2. L EPR créé, il est utilisé pour invoquer les opérations pour commencer le commerce. 3. Le MarketService interroge le DefaultIndexService (Grid Registry) en apportant la localisation pour obtenir l information concernant les vendeurs et les acheteurs enregistrés avec les préférences à une localisation particulière pour laquelle l instance de ce service du marché est en exécution. 4. Le DefaultIndexService retourne un EPR du service vendeur et de l acheteur intéressé dans la localisation donnée. 5. Le MarketService compare les propriétés des ressources du service vendeur et de l acheteur en utilisant les EPR extraits. Si le mode du commerce est directe pour l acheteur et si ses propriétés ressources correspondent avec celles requises par un acheteur, le commerce est exécuté en invoquant les opérations sur les ressources du vendeur et l acheteur pour ajuster les quantités des produits et les gains pour un vendeur, la quantité du produit et le montant dépensé pour l acheteur. Ce qui a été présenté concerne le commerce direct. Ils ont également traité le mode indirecte en incluant les frais de déplacement par rapport à des zones de marchés dispersées. WSRF a été utilisé pour décrire les web services avec état, la notification entre autre. 66

5. Synthèse des solutions Chapitre III : Les Processus Métiers et les concepts des Grids Les solutions présentées utilisent à la base les grid services pour encapsuler et virtualiser les applications des entreprises. La définition des processus métiers Que ça soit [76] où l OGSI a été utilisé ou dans ([83] et [77]) qui ont utilisé le WSRF, les processus métiers sont définis avec des web services à état à savoir les grid services. Le fournisseur d information Registre : Dans [83] la spécification WS-ServiceGoup du WSRF a exploité pour le registre des ressources, contrairement au [75] qui a utilisé l UDDI pour la publication des grid services. Médiateur La découverte des services s effectue pour [77] à travers le composant services d information et dans [76] à travers le navigateur des processus métiers. La sémantique Dans [77], l aspect sémantique a été intégré via des ontologies et des règles sémantiques pour le vocabulaire des produits agricoles. Seulement ces solutions ne traitent pas la collaboration des processus métiers. Elles traitent la gestion des gestionnaires des processus métiers [76], proposent une plateforme de collaboration e-business [75], une solution pour l automatisation des processus métiers [77] et un système qui couvre une application pour le processus du commerce dans le domaine de l agriculture (Agricultural Marketing Process) [83]. Ce sont des solutions propriétaires et sectorielles [75] et [83]. Même si ces solutions n ont pas traité l aspect de collaboration des processus métiers, elles ont par ailleurs utilisé les concepts du Grid (Organisation virtuelles et web service à état ou grid services) qui pourraient permettre de définir une solution de collaboration des processus métiers. 6. Conclusion Les grid services ou web services à état représentent une évolution naturelle des web services pour permettre une collaboration à grande échelle. Ce chapitre s est porté essentiellement portés sur la technologie Grid avec ces différents concepts. Ces derniers comportent les organisations virtuelles et les grids services. Les grid services sont définis à travers l OGSA et spécifiés avec l OGSI ou le WSRF. Ce chapitre s est également porté sur les solutions de qui combinent les processus métiers avec les concepts des grid et nous avons vu que ces 67

Chapitre III : Les Processus Métiers et les concepts des Grids solutions ne se traitent pas la collaboration des processus métiers. Ainsi le prochain chapitre fera part de notre proposition. 68

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Chapitre IV: Collaboration des Processus Métiers basée sur le Web Service Resource Framework (WSRF) Résumé: Ce chapitre a pour objectif de décrire l architecture proposée pour une collaboration de Processus Métiers qui se basent sur les concepts du Grid à savoir les Organisations Virtuelles et les Grid Services (Web Service à Etat). Ces derniers sont décrits avec le Web Service Resource Framework (WSRF). 1. Introduction La collaboration des processus métiers est essentielle dans l environnement compétitif dans lequel les entreprises évoluent. La réduction du cycle métier et du coût et la qualité de service sont de rigueur. Plusieurs solutions existent, seulement, elles se limitent au paradigme Service Web. Il serait donc judicieux d étendre ses solutions avec d autres paradigmes (tel que ceux offerts par les Grids) qui traiteront les exigences d une collaboration efficace. Néanmoins, des solutions intégrant les concepts du Grid existent. Cependant, ces solutions sont sectorielles et propriétaires et de surcroît ne traitent pas la collaboration des processus métiers. L objectif principal de ce travail est de proposer une architecture de collaboration qui se base sur les solutions existantes en y intégrant les concepts des Grids. Ainsi, ce chapitre a pour objectif de présenter notre proposition qui traite la collaboration qui se base sur les concepts du Grid. 2. Pourquoi utiliser les concepts du Grid dans la collaboration des Processus Métiers? Aujourd hui, les entreprises ont besoin de souplesse, d efficacité, de capacité de monter en puissance et d interopérabilité pour s adapter à des environnements métier en évolution permanente et pour une collaboration réussie entre plusieurs partenaires. Cette collaboration, dont la composante clé est le processus métier nécessite ([83] et [77]): Un support pour la persistance de l état. 69

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Une reprise après échec ou erreur en prenant en considération les interactions précédentes (historique des interactions). Une notification de changement d état. Une coordination entre les participants. Une gestion du cycle de vie des processus métiers (pour permettre la persistance de l état). Ces derniers sont insuffisamment traités dans les solutions existantes de collaboration des processus métiers, mais sont présents et offerts par le WSRF. Aussi, les performances recensées sur les applications des concepts des Grids dans des cas réels, pour des solutions e-business et e-commerce, ont renforcé notre orientation pour l utilisation du WSRF pour une collaboration efficace. Même si ces applications sont sectorielles, et surtout qu elles ne traitent pas la collaboration. Notre contribution exploite la puissance des concepts du Grid et particulièrement le concept de web service à état, les organisations virtuelles, avec celle des solutions existantes. Comme illustré dans la figure ci-dessous, notre architecture de collaboration exploite les solutions existantes en intégrant les Grids avec ses apports. Ces apports peuvent être résumés comme suit : - Support pour la persistance de l état. - Support de notification. - Gestion du cycle de vie de la ressource. - Reprise après un crash en prenant en considération l historique des interactions comme cité dans [69]. Figure 25: Fondement de l approche. 70

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF 3. Approche adoptée Notre solution se base sur l approche utilisée par [55], [61], [60], [63] et [64] qui consiste en: A. la définition de la collaboration inter-entreprises sous forme d un processus métier global qui représente le contrat, B. la distribution du processus métier global en des processus propres à chaque participant, C. et enfin, l exécution décentralisée des processus au niveau de chaque participant. Les participants font partie d une organisation virtuelle. Le concept «organisation virtuelle» qui est né avec celui des Grids, dans les années 90, pour permettre une collaboration d individus dispersés géographiquement pour atteindre un objectif commun. Le cas présent est une collaboration d entreprises à travers leur processus métier. Cette organisation virtuelle peut traiter d autres collaborations avec une modification de participants car elle est par nature dynamique. L expression de nouveaux besoins (collaboration) au sein de cette même organisation virtuelle mais dans le même domaine est possible. a. Les caractéristiques des Web Services à Etat Les web services à état ont les caractéristiques suivantes : Le maintien d un état interne (persistance de l état). Cet état résulte d une invocation d un client. La tracabilité de chaque invocation. La définition d une durée de vie. b. Les caractéristiques de l Organisation Virtuelle L organisation virtuelle a comme caractéristiques: La structure et les membres de la VO sont en constante évolution. Les membres d une VO peuvent participer dans différentes collaborations. Les membres des organisations virtuelles peuvent basculer d une OV à une autre 71

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Les ressources, les services et les individus que comprend une OV peuvent être mono ou multi institutionnels, homogènes ou hétérogènes. L organisation virtuelle existe pour un objectif spécifique. 4. Objectifs du modèle proposé L objectif du modèle proposé est de mettre en place une architecture qui fonctionne dans un mode horizontal, c est-à-dire, un modèle qui propose des services génériques et standardisés pour la majorité des secteurs d activités et qui peuvent être adaptés à des domaines et des contextes particuliers. L architecture proposée fournit un environnement collaboratif permettant aux participants de disposer d un système d échange efficace et fiable et dans lequel l intégration des entreprises se fait avec beaucoup de facilité. Notre but est de proposer une architecture qui répond à un certain nombre d objectifs: Une plateforme générique (horizontale) indépendante Le principal objectif que nous assignons à notre démarche est la généricité. Nous voulons que l architecture proposée soit utilisable dans un maximum de situations de collaboration inter-entreprise. Une solution qui stimule la réutilisation Le deuxième objectif autour duquel est construite la démarche est de favoriser au maximum la réutilisation. L utilisation de l organisation virtuelle permet à différents participants d y adhérer sans modification des nouveaux systèmes intégrés pour des objectifs communs. Cette organisation virtuelle peut permettre d autres ouvertures pour d autres collaborations selon les services proposés et enregistrés dans les registres OV (Organisation Virtuelle). 5. Schéma général Le schéma général de notre solution [89] comporte des participants, un contrat et un gestionnaire. Les participants interagissent à travers une organisation virtuelle, à la base d un contrat. Le gestionnaire supervise cette interaction. La figure ci-dessous illustre la relation entre participants dans une OV, caractérisée par un contrat (processus collaboration). 72

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Organisation Virtuelle (OV) Entreprise 3 Entreprise 2 Contrat Gestionnaire Entreprise 2 Figure 26: Relation entre les partenaires dans une OV. 5.1 Architecture proposée La figure 27, illustre l architecture de la collaboration, qui consiste en COLLABORATION GESTIONNAIRE ENREGISTREMENT ENCAPSULATION PROCESSUS METIERS PUBLICS Figure 27: Architecture de la collaboration. 73

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF L architecture comporte : 1. Les processus métiers publics : pour des raisons de sécurité et de confidentialité, les entreprises séparent entre les processus métiers privés et publics. Ces derniers, tel que illustrés dans la figure 28, sont définis sur la base des systèmes métiers (CRM, SCM,..) et des systèmes propriétaires de l entreprise. Les processus métiers publics représentent le comportement exposé de l entreprise. Cette dernière sépare entre l aspect public et privé des processus métiers pour ne pas révéler ses systèmes décisions et de gestion de données internes à leurs partenaires d affaires. Mais également, pour libérer l aspect implémentation pour ne pas affecter les processus métiers publics. PROCESSUS METIERS PUBLICS ERP SCM CRM BPM Solutions propriétaires (Legacy system) Figure 28: Les Processus Métiers Publics. 2. L encapsulation: encapsuler les processus métiers publics signifie les exposer à travers une interface standard. Le but de l encapsulation est de : Faciliter l accès aux opérations offertes par les processus métiers publics. Permettre un faible couplage. Protéger les données et les processus métiers internes de l entreprise. Assurer la confidentialité des données. Certes, certains de ces objectifs peuvent être obtenus avec les web services sans états, seulement, dans le cas des processus métiers et particulièrement pour un objectif de collaboration, l état est un concept très important qui doit être persistant d où l utilisation des web services à état. 74

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF 3. Le registre: il a pour rôle d enregistrer les processus métiers encapsulés (web services à état). Il permet de garder trace des ressources impliquées dans les transactions en cours. Les participants y enregistrent leurs processus métiers encapsulés pour qu ils puissent être découverts et invoqués. 4. Le gestionnaire: Il représente le point d entrée de l organisation virtuelle pour le client. Il est responsable de la coordination entre participants, de la création, de l instanciation et de la destruction des web services à état. Il supervise l exécution de chaque partie du processus collaboratif au niveau de chaque participant et responsable de la reprise ou de la poursuite de l exécution après échec ou d éventuelles erreurs. 5. La collaboration : la collaboration définit l objectif commun des participants. Elle est représentée par un contrat entre ces derniers. La collaboration est définit comme un processus métier collaboratif, où les rôles de chaque participant y sont désignés. Chaque participant aura une instance du contrat et n exécutera que les parties qui lui sont assignées. 5.2 Description de chaque module Après une description générale des différents modules de notre architecture, et comme schématisé dans la figure 29, nous allons à présent, détailler ces composants avec leurs correspondant dans les spécifications WSRF. 75

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF WS-Notification WS-ResourceLifetime WS-BaseFaults Collaboration Gestionnaire Registre Définition des rôles de chaque participant et de l objectif commun WS-ServiceGroup Encapsulation Web service à état + Ressource Web service à état WS-Resource PROCESSUS METIERS PUBLICS ERP SCM CRM BPM Solutions propriétaires (Legacy system) Figure 29: Correspondance entre composants de l'architecture et les spécifications WSRF. L encapsulation : Les processus métiers sont encapsulés dans des grid services sur la base du Implied Ressource Pattern (voir figure 30). Les processus métiers publics sont exposés comme des WS-Resources. L encapsulation des processus métiers publics est nommée «Service Public Business Process» (SPBP). 76

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Entrée Web Service à état Sortie Processus métiers publics Sortie Entrée Figure 30: Encapsulation des Processus Métiers Publics. Lors de leur invocation, une ressource sera crée (figure 31). La ressource et le web service seront représentés avec WS-Ressource [69]. Ce denier aura un identifiant unique, un état (Ressource qui peut être projeté comme un document XML), et une durée de vie (voir figure 5). L identificateur de la ressource est le EndPoint Reference (EPR). L accès au WS- Resource (processus métier public encapsulé) est formé par la paire web service et la ressource se fera avec WS-Addressing et SOAP. Les changements d état des données des processus métiers publics (état) seront notifiés à chacun des participants. Le WSnotification permet une notification asynchrone des changements d état d une manière standardisée et la coordination entre les partenaires. L état peut être la valeur d un bon de commande, ou la quantité disponible d un certain produit. Il est représenté par WS-ResourceProperties. Les propriétés définissent l état du processus métier public. Elles peuvent être lues, modifiées et interrogées, en utilisant les messages standard des web services à état à savoir getresourceproperty, setresourceproperty, getmultipleresourceproperties et queryresourceproperties. La durée de vie est définit par la spécification WS-ResourceLifeTime du WSRF. 77

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Invocation / interrogation WS-Addressing + SOAP Processus Métier Public encapsulé WS-Resource WS-Notification Ressource Figure 31: Invocation d un Processus Métier Public encapsulé. Manager ou gestionnaire : le gestionnaire représente l implémentation du implied ressource pattern. Il est responsable de la création et la destruction des ressources. WS-ResourceLifetime est utilisé pour gérer le cycle de vie des processus métiers publics. Le cycle de vie des ressources est très important pour la persistance de l état. WS-BaseFaults sera utilisé pour fournir un report lors d une erreur d invocation d un Web service. Le registre : Les participants publient leurs processus métiers encapsulés dans un registre pour permettre leur découverte et invocation (figure 32). Le registre de l OV que nous proposons repose sur la spécification WS-ServiceGroup du Web service Resource Framework (WSRF). Il peut être utilisé pour former une large variété de collections de web services ou de WS-Resource ayant un certain nombre de critères ou de WS-Resource et incluant les registres et les WS-Resource associés [87]. Le WS-ServiceGroup sera utilisé comme un registre des participants de la collaboration. Il permet également de garder trace des transactions telles que mentionnées dans [83]. L avantage de l utilisation de cette spécification dans la description du registre est la traçabilité des exécutions des web services à état. 78

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Processus Métier Public + Web Service Rajout d une entrée WS-Resource <wssg:add> <wssg:memberepr> wsa:endpointreferencetype </wssg:memberepr> <wssg:content> {any} </wssg:content> <wssg:initialterminationtime> xsd:datetime </wssg:initialterminationtime> </wssg:add> Registre <wssg:content> {any} </wssg:content> Figure 32: Enregistrement des Processus Métiers Publics encapsulés. Synchronisation des registres de l entreprises avec le registre le l Organisation Virtuelle Le but du registre de l OV est d offrir une place partagée et universelle où chaque entreprise, quelle que soit sa taille, son domaine d activité et sa localisation, et qui adhère à l organisation virtuelle, pourrait publier les services dont elle dispose, et de trouver de façon dynamique les services dont elle a besoin. Le fait de répertorier les différents services offerts par une même organisation est primordial si l on désire que ces services soient utilisés et partagés. L importance d avoir un annuaire central est de garantir la découverte des services fournis par les organisations. C est exactement le même cas pour une page Web qui ne sera pas visitée si elle n est pas référencée dans un moteur de recherche. En d autres mots, ce registre permet de déterminer les informations sur les entreprises et les services, afin de permettre à la communauté qui partage cet annuaire d y avoir accès. Ce registre doit fournir un schéma général et chaque entreprise doit publier son profil ainsi que ses services conformément à ce schéma. 79

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Registre privé de l entreprise UDDI ou Registre ebxml (ebrim) L Organisation Virtuelle Nouvelle entrée/suppression dans le registre privé de l i Agent de synchronisation Registre privé de l entreprise Notification aux autres participants de l OV Registre de l OV ( WS-ServiceGroup) UDDI ou Registre ebxml (ebrim) ServiceGroupEntry ServiceGroupRegistration Registre privé de l entreprise UDDI ou Registre ebxml (ebrim) Figure 33: Synchronisation entre registre privé de l'entreprise et le registre de l'ov. Le fonctionnement de l entreprise est représenté par un ensemble de processus. Ceuxci sont en relation étroite avec les composants du système d information. A cet effet, l intégration de nouveaux services doit être mise en oeuvre de manière à la fois pragmatique et rigoureuse. La clé est donc, la synchronisation entre les registres privés de l entreprise et du registre de l organisation virtuelle (OV) est nécessaire pour que les autres participants de l OV puissent être informé des autres services 80

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF qu ils offrent hormis les autres services pour lesquels ils collaborent et ainsi donner lieu à d autres collaborations. L enregistrement d un nouveau service (processus métier public encapsulé) est notifié aux autres participants de l organisation virtuelle, ceci peut intéresser des participants et amener à la définition d autres collaborations. Un agent est préconisé pour la synchronisation nommé «agent de synchronisation» (voir figure 33). Le contrat : Une fois les partenaires enregistrés, il est nécessaire de se mettre d accord sur les différentes étapes de déroulement du scénario d échange qui est le processus métier collaboratif et appelé également le contrat. Un processus métier représente un ensemble ordonné d interactions. Chaque interaction représente un échange atomique de messages entre partenaires. Le rôle de chacun y est définit. Ce contrat peut être sous la forme d une chorégraphie globale. La communication entre les différents partenaires se fait à travers le WS-Addressing et le SOAP. 5.3 Fonctionnement de l architecture Nous allons à présent, décrire le fonctionnement global de notre architecture (figure 34). 81

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Virtual Organization (VO) (5) (6) Entreprise A PBP1 SPBP1 PBP2 SPBP2 Publication Notification Contract (2) Registre VO (4) Notification Publication (3) Entreprise B PBP1 SPBP1 PBP2 SPBP2 Gestionnaire (Manager) Requête (1) Figure 34:Détails de l architecture proposée. Le besoin du client (ou du marché) formulé sous forme de requête (1) sera soumise à l organisation virtuelles intéressée et pouvant répondre à cette dernière. Le gestionnaire (manager) représente le premier point de contact dans l organisation virtuelle. Par son biais, le besoin est soumis. Cette requête sera traduite sous forme de contrat (2) définit et approuvée par les participants de cette OV voulant collaborer. Ce contrat reflète le besoin du client et l accord entre les différents participants dans cette collaboration. Les participants ayant préalablement enregistré leurs processus métiers publics encapsulés dans le registre de l OV. L enregistrement (3) de tout nouveau service peut se faire à tout moment, et les autres participants seront notifiés (4). La notification concerne également l exécution finalisée ou le changement dans les données du processus métiers encapsulé (6). Finalement, l interaction s effectue entre les différents partenaires (5). 82

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF Caractéristiques de l architecture Notre architecture permet : Autonomie des participants Notre solution permet une autonomie des processus métiers internes de l entreprise. Cette autonomie est réalisée avec la séparation entre processus métiers publics et privés. Les changements opérés sur les processus publics n affectent pas les processus internes de l entreprise, ces processus publics reflètent un comportement exposé, pour interagir avec les participants (partenaires). Tous les participants sont indépendant les uns des autres. La relation entre eux réside dans la définition du contrat. Préserve la confidentialité des participants est l un des avantages les plus important offert par l encapsulation par le WS-Resource, car les données sont accessible via des opérations spécifiques qui fournissent un point de contrôle et d intégrité de données. Reprise après échec ou défaillance après défaillance ou autre. La flexibilité des participants permise par la définition des organisations virtuelles. 5.4 Implémentation proposée pour l architecture Dans ce qui suit, nous allons présenter quelques outils qui permettent l implémentation des Processus Métiers Publics avec des web services à état. - WSRF.Net: est un ensemble de librairies et d outils et d applications qui implémentent le WSRF et WS-Notification. Il représente l évolution du OGSI.NET. Il intègre plusieurs technologies de Microsoft tel que WSE (Web Service Enhancements) et ADO.NET. L utilisation de cet outil est très difficile telle que souligné dans [90]. - Globus Toolkit 4.0 Il reste le plus référencer dans littérature. Il est le résultat des recherches de l institut d Argonne en Arizona. Communément appelé GT, dont la version 4 représente l implémentation du Web Service Resource Framework Il 83

Chapitre IV : Collaboration des Processus Métiers basée sur le WSRF comprend 15 composants répertorié en 4 ensembles assurant la sécurité (community Autorisation, Delegation.), la gestion des données (tel que OGSA-DA) la gestion de l exécution (tel que la gestion de l allocation des resources, WebMDS) et finalement l exécution commune tel que java C WS Core. 6 Conclusion Le WSRF a été utilisé pour définir les Web Service à état ou Stateful Web Services. Ces derniers encapsulent les processus métiers publics de l entreprise. La spécification WS- ServiceGroup du WSRF a également été utilisée pour construire des collections de services web. De ce fait, le WS-ServiceGroup représente un registre des participants de la collaboration comme utilisé dans [83]. Nous avons proposé une architecture de collaboration qui se base sur le WSRF et sur les solutions de collaboration fondées sur les services web. Ceci permet une notification asynchrone des changements d état et donc une coordination entre les différents participants, un support pour la persistance de l état pour permettra une reprise avec prise en compte de l historique des interactions. 84

Conclusion générale et perspectives Conclusion Générale Les tendances actuelles envers un accroissement de la globalisation et de l externalisation des services pour les partenaires ont fait ressentir le besoin d améliorer le niveau de collaboration, particulièrement pour les processus métiers inter-organisationnels pour les échanges inter-entreprises dans le e-commerce. Des standards qui offrent un framework pour les échanges inter-entreprises, ont vu le jour tel qu ebxml ou encore RosettaNet. Les participants dans ces échanges adoptent toutes les spécifications contenues dans ces frameworks. Ce qui représente un inconvénient pour les participants. D où notre intérêt pour la définition d une collaboration des processus métiers qui représentent l élément moteur de ces échanges pour que les entreprises puissent atteindre leurs objectifs respectifs et communs. Pour cela, nous nous sommes établis comme première étape dans notre travail, l étude des différentes solutions de collaboration existantes. Ces solutions qui sont sectorielles et propriétaires. Cette étude a découlé sur la définition des critères que doit comporter une collaboration de processus métiers efficace. Ces critères sont: la persistance de l état contenue dans le processus métier, un support pour la notification du changement d état et la gestion de la durée de vie des processus métiers. De ce fait, notre intérêt s est orienté vers les Grid. Cette technologie qui s est faite parler d elle par son succès dans le domaine du E-science, dont l objectif primordial qui lui est assigné, est la collaboration à une large échelle pour atteindre des objectifs communs. Le Grid renferme principalement deux concepts. Le premier concept étant les Grid services appelés également web services à état qui résultent de la convergence des web services avec celle des technologies Grid. Le web service à état est décrit avec la spécification Web Service Resource Framework définie par le Global Grid Forum (GGF). Le WSRF regroupe un certain nombre de spécifications. Ces spécifications ont pour objectif principal la gestion de l état d une ressource lors de l invocation et l exécution d un web service. Mais également, la notification l aspect très important dans une collaboration d affaire qui est lors des changements d état qui permet la coordination entre partenaires. Ainsi, nous nous sommes basés sur l approche de collaboration, qui consiste en la définition d un contrat contenant les rôles et les tâches de chaque participant. Et les processus métiers publics de chaque participant englobés dans des web services à état. Cette architecture repose entièrement sur les spécifications du WSRF. 85

Conclusion générale et perspectives Le second concept étant les organisations virtuelles qui consiste en des regroupements de ressources hétérogènes dispersées géographiquement. Elle regroupe les participants ayant pour objectif la collaboration afin de répondre à un besoin du marché. La deuxième étape dans notre travail consiste en l étude des différentes solutions et propositions combinant les processus métiers avec celles des Grids. Ainsi, la puissance recensée dans l intégration des Grid dans le e-commerce mais qui ne traitent pas l aspect collaboratif des processus métiers a renforcé notre orientation quant au choix de l intégration des concepts du Grid dans la collaboration des processus métiers. De ce fait, nous avons proposé une architecture de collaboration qui se base sur ces deux concepts. Le contrat est le lien entre les différents partenaires. Ce contrat représente la chorégraphie globale définissant où le rôle de chaque partenaire y est définit. Nous nous avons définit les fonctionnalités de chaque module comporté dans l architecture de collaboration qui se base sur le WSRF proposée. Comme perspectives à notre travail, l implémentation de l architecture, avec Globus ToolKit 4 (GT4) ou encore le WSRF.Net serait une concrétisation de notre contribution. L extension du BPEL ou WSCL pour la chorégraphie globale, car les langages avec leur définition actuelle reste limité à une chorégraphie entre web services sans état. Une dernière perspective, est l étude de la décomposition de la chorégraphie. 86

Bibliographie Bibliographie [1] I. Foster, C. Kesselman, S.Tuecke «The Anatomy of the Grid Enabling Scalable Virtual Organizations» Intl J. Supercomputer Applications, 2001. [2] GRIDORG. Grid computing. [En Ligne]. Disponible sur http://www.grid.org/about/gc/ (Consulté Le 23/08/2006) [3] I. Foster. «What is the Grid? A Three Point Checklist».2002 [4] R.Bbuyya, S.Venugopal «A Gentle Introduction To Grid Computing And Technologies» Computer Society of India, CS Communication.2005 [5] D. Talia, P.Trunfio «Toward A Synergy Between P2P And Grids»IEEE Internet Computing, 2003 [6] R. Butler, D. Engert, I. Foster, C.Kesselman, S.Tuecke, J Volmer, VonWelch_ «Design and Deployment of a National-Scale Authentication Infrastructure» 1999 [7] Clip2 «The Gnutella Protocol Specification v0.41 Clip2» Technical. report, Clip2.com 2002 [8] IBM. Evolution Technologique [En Ligne] Disponible sur: http://www-5.ibm.com/ebusiness/ch/fr/evolving/ondemand/technology/grid.html (Consulté Le 23/08/2006) [9] W3C.Web Services Architecture [En Ligne] Disponible sur: «http://www.w3.org/tr/2004/note-ws-arch-20040211/» [10] F. Curbera, M.Duftler, R. Khalaf, W.Nagy, N.Mukhi,, S.Weerawarana, T.J.Watson «Unraveling the Web Services An Introduction to SOAP, WSDL and UDDI», 2002 [11] DAML-S Coalition «DAML-S: Web Service Description for the Semantic Web», 2002 [12] W3C. W3C Web Service-Adressing [En Ligne]. Disponible sur: http://www.w3.org/submission/ws-addressing/ (Consulté Le 02/10/2006) [13] C. Comito, D. Talia, P.Trunfio «Grid services: principles, implementations and use». Int. J. Web and Grid Services. Vol 1, No1, 2005. [14] S. Tueck, K. Czajkowski; I.Foster, J. Frey, S.Graha, C. Kasselman, T. Maquire, T. Sandholm, D, Snelling, P.Vanderbilt. «Open Grid services Infrastructure (OGSI)» 2003 [15] I. Foster, C. Kasselman «Open Grid Services Architecture» 2005 [16] K.Czajkowski, D. Ferguson, I.Foster,J.Frey, S.Graham, T.Maguire, D. Snelling, S.Tuecke «From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring & Evolution».2004 [17] D.Talia «The Open Grid Services Architecture: Where the Grid Meets the Web»IEEE.2002 [18] I. Foster,C.Kesselman, J.M. Nick,S.Tuecke «Grid services for distributes system integration» IEEE.2002 [19] K.Donald, F. Ferguson,I.Foster,. J.Frey,S.Graham, I.Sedukhin, D.Snelling, S.Tuecke, W.Vambenepe 87

Bibliographie «The WS-Resource Framework Version 1.0» 2004 [20] T. Sandholm, J.Gawor «Globus Toolkit 3 Core A Grid Service Container Framework».2003 [21] T. Maguire, M. Williams,J. Joseph «GWSDL to WSDL 1.1 Transformation (GWSDL2WSDL1.1) Version 0.1 (draft)»2003 [22] S. Reynaud. «Développement de services de grille standardisés : retour d expérience»..les Journées Réseaux JRES. 2003 [23] I. Foster, D. Gannon,H. Kishimoto, Jeffrin J. Von Reich, «Open Grid Services Architecture Use Cases» 2004 [24] I.Foster, C.Kesselman, M.Jeffrey,N.Tuecke «The Physiology of the Grid / An Open Grid Services Architecture for Distributed Systems Integration» 2001 [25] D.Gannon, M.Christie, O.chipara, L. Fang, M. Farrelle, G.Kandaskwany, W. Lu, B.Plale, A.Slominski, A.Sarangi, Y. L.Simmhan. «Building Grid Services for user portals». 2002 [26] W3C.Le W3C recommande Web Services Addressing 1.0.Web Services-Adressing [En Ligne]. Disponible sur: http://www.w3.org/2006/04/wsaddressing-pressrelease.html.fr (Consulté Le 02/10/2006) [27] B. Medjahed, B. Benatallah, A.Bouguettaya, A.H.H Ngu, A.K. Elmagarmid «Business-to-business interactions : issues and enabling technologies».the VDLP Journal.2003 [28] S.Aissi, P. Malu, K.Srinivasan «E-Business Process Modeling: The Next Big Step». IEEE 2002. [29] Business Internet Consortium (BIC) XML Convergence Workgroup «High-Level Conceptual Model for B2B Integration». 2001 [30] Microsoft. Microsoft BizTalk Server [En Ligne] Disponible sur: http://www.microsoft.com/biztalk/default.mspx (Consulté Le 16/10/2006) [31] ebxml Technical Architecture Project Team 3 «ebxml Technical Architecture Specification v1.0.4 2».2001 [32] C.Huemer «UMM-Consistent B2b Analysis & Design on Top of Top of ebxml and Web». Tutoriat@EEE-2005 [33] R.Gong «Business Process Collaboration: The Essence From A Modeling Point Of View» DERI Scientific Review.2005 [34] S.Schlegel «The ebxml Collaboration Protocol Agreement Formation Process» Master of Science (Computer Science).At Curtin University of Technology. 2005. [35] RosettaNet.www.rosettanet.org (Consulté en Juillet 2006) [36] T.Andrews, F.Curbera, H.dholki, Y.Goland «Business Process Execution Language for Web Services Version 1.1».2003 [37] S.Thatte «XLANG : Web Services For Business Process Design».2002 [38] J.Chauvet «Services Web avec SOAP, WSDL, UDDI, ebxml» Eyrolles.2002 [39] T.Gardner «UML Modelling of Automated Business Process with a Mapping to BPEL4WS».2003 [40] F.Leymann, 88

Bibliographie «Web Services Flow Language (WSFL1.0)».2001 [41] L.Zhang, H.Li, H.Lam «Toward a Business Process Grid for Utility Computing». IT PRO.2004 [42] Business Internet Consortium (BIC) Whitepaper «High-Level Conceptual Model for B2B Integration». 2002 [43] RosettaNet Implementation Framework: Core specifications, publié par RosettaNet [En Ligne]. Disponible sur: http://www.rosettanet.org/ (Consulté Le 02/09/2006) [44] ebxml specifications. Publié par OASIS RosettaNet [En Ligne]. Disponible sur: http://www.ebxml.org/ (Consulté Le 02/09/2006) [45] IBM. Developing grid computing applications, Part 1 [En Ligne] Disponible sur http://www-128.ibm.com/developerworks/grid/library/gr-grid1/ [46] Tanguy Crusson «Business Process Management De la modélisation à l exécution Positionnement par rapport aux Architectures Orientées Services»Intalio.2003 [47] Marcel Bijlsma, Erwin Fielt, Johan Koolwaaij «Web Services and Business-to-Business Integration Mapping promises to reality» https://doc.telin.nl/dscgi/ds.py/get/file-22582 2002 [48] Christoph Bussler «The Role of B2B Protocols in Inter-Enterprise Process Execution» F. Casati, D. Georgakopoulos, M.-C. Shan (Eds.): TES 2001, LNCS 2193, pp. 16-29, 2001. Springer-Verlag Berlin Heidelberg 2001 [49] W3C. Web Services Choreography Description Language Version 1.0 http://www.w3.org/tr/2005/cr-ws-cdl-10-20051109/ [En Ligne] [50] Dongsong Zhang «Web Services Composition For Process Management In E-Business» Department of information system, university of Maryland, Baltimore county.2003. [51] Gregory Mentzas, Christos Halaris «Workflow On The Web: Integrating E-Commerce And Business Process Management». International journal of e-business strategy management, Vol. 1, No. 2, pp.147-157. 1999. [52] Jan Mendling, Gustav Neumann, Markus Nüttgens. «A Comparison Of XML Interchange Formats For Business Process Modeling» EMISA.2004.P129-P140 [53] Wasim Sadiq, Shazia Sadiq, Karsten Schultz. «Model Driven Distribution Of Collaborative Business Processes».IEEE (SCC 06).2006. [54] Razika Driouche, Zizette Boufaïda, Fabrice Kordon. «Towards Integrating Collaborative Business Process Based on a Process Ontology». Proceedings of the 17th International Conference on Database and Expert Systems Applications (DEXA'06).IEEE. 2006 [55] Jae-yoon Jung,Wonchang, Hur, and Suk-Ho Kang, Hoontae Kim «Business Process Choreography for B2B Collaboration» IEEE Computer Society 2004 [56] Kumar Bhaskaran, Je,-Yao Chung, Rajas Das, Terry Health, Santhosh Kumaran, Prabir Nandi. «An E-Business Intergration & Collaboration Platform For B2B E-Commerce». IEEE. 2001 [57] Belinda M. Carter, Maria E. Orlowska «On the Execution of Collaborative Business Processes» Proceedings of the 17th 89

Bibliographie International Conference on Database and Expert Systems Applications (DEXA'06).2006. IEEE. [58] Muriel Mignerat, Benoit A. Aubert «Rapport de Projet : Prototypes avancés en commerce électronique 2002RP-03. Panorama des Systèmes d Intégration Inter- Organisationnels : Aspects Technologiques». CIRANO: centre universitaire de recherche en analyse des organisations. Montréal Janvier 2002 [59] Umeshwar Dayal, Meichun Hsu, Rivka Ladin «Business Process Coordination: State of the Art, Trends, and Open Issues». Proceeding of the 27 th VLDB Conference, Rom, Italy.2001 [60] Qiao Xiaoqiang, Wei Jun «A Decentralized Services Choreography Approach for Business Collaboration» IEEE International Conference on Services Computing (SCC'06).2006.IEEE. [61] Qiming Chen, Meichun Hsu «Inter-Enterprise Collaborative Business Process Management» Proceedings of the 17th International Conference on Data Engineering (ICDE.01). 2001 IEEE [62] Paul Grefen «Towards Dynamic Interorganizational Business Process Management» Proceeding of the 15 th IEEE International Workshops On Enabling Technologies Infrastructure For Collaborative Enterprises. (WETICE 06) IEEE.2006. [63] Aries Tao Tao, Jian Yang, Hongyu Jia «Business Collaboration Development: A case study in Capital Market» Proceeding of the 10 th IEEE international Entreprise Distributed Object Computing Conference (EDOC 06). IEEE 2006 [64] Karsten A.Schulz, Maria E.Orlowska «Architectural Issues or Cross-Organisational B2B Interactions» Proceedings of the 21st International Conference on Distributed Computing Systems. (ICDCSW) IEEE.2001 [65] Brigit Hofreiter, Christian Huemer, Marco Zapietal «A Business Collaboration Regisry Model on Top of ebrim» IEEE International Conference on e-busines Engineering (ICEBE 06).IEEE 2006 [66] Christoph Bussler «B2B Integration Technology Architecture» Proceedings of the 4th IEEE Int l Workshop on Advanced Issues of E-Commerce and Web-Based Information Systems (WECWIS 2002).2002 IEEE [67] Rer Schmidt «Web Services Based Execution of Business Rules» [68] Ian foster, karl czajkowski, donald f. Ferguson, jeffrey frey, Steve graham, tom maguire, david snelling, and steven tuecke «Modeling and Managing State in Distributed Systems: The Role of OGSI and WSRF» Proceedings of the IEEE, vol. 93, no. 3. 2005 [69] Ian Foster, Jeffrey Frey, Steve Graham,Steve Tuecke,Karl Czajkowski,Don Ferguson, Frank Leymann, Martin Nally, Igor Sedukhin, David Snelling, Tony Storey, William Vambenepe,Sanjiva Weerawarana «Modeling Stateful Resources with Web Services»Version 1.1. 03/05/2004 [70] W3C. W3C Recommendation 26 June 2007 «Web Services Description Language (WSDL) Version 2.0» http://www.w3.org/tr/2007/rec-wsdl20-20070626 [En Ligne] [71] Business Process Management Initiative (BPMI) «Business Process Modeling Notation (BPMN) Version 1.0».2004 90

Bibliographie [72] David Hollingsworth «Workflow Management Coalition: The Workflow Reference Model» 1995. [73] http://www.fastwater.com [74] Project CrossFlow Overview. http://www.crossflow.org (Consulté Le 15 Juillet2007) [75] Lin chun-mei, Yang Hong-shan, He Yue. «Collaborative e-business Plattform Based on Grid Services»Proceeding of The First International Conference On Semantics, Knowledge, And Grid.IEEE 2006 [76] Jun-Jang Jeng, Henry hang et Jen-Yao chung «BPMM: A Grid-Based Architectural Framework For Business Process Meta Management». Proceeding Of The 2003 Symposium On Applications And The Internet.IEEE.2006 [77] Zakir Laliwala, Pratreek Jain, Sanjay Chaudhary «Semantic Based Service Oriented Grid Architecture For Business Processes» International Conference on Services Computing. IEEE 2006. [78] Chris Peltz, Hewlett Packard, Co «Web Services Orchestration and Choreography». IEEE 2003 [79] Andreas Savva, Toshiyuki Suzuki, Hiro Kishimoto «Business Grid Computing Project Activities» FUJITSU Scientific. Technical. Journal 40,2,p.252-260 2004 [80] http://www.w3.org/tr/wsci [81] Chris Peltz, Hewlett Packard, Co. «Web Services Orchestration A Review Of Emerging Technologies, Tools, And Standards» January 2003 [82] Wolfgang Emmerich, Ben Butchart, Liang Chen and Bruno Wassermann, Sarah L.Price «Grid Service Orchestration Using the Business Process Execution Language BPEL» 2005 [83] Asif Akram, Sanjay Chaudhary, Prateek Jain, Zakir Laliwala, Rob Allan «Grid Business Process: Case Study» Securing Web Services: Practical Usage of Standards and Specifications ISBN 1599046393. Août 2007. [84] CEFACT «UN/CEFACT Modeling Methodology (UMM): User Guide» 2003 [85] OASIS «Web Services Resource 1.2 (WS-Resource) Draft 01» 2005 [86] Syriram Krishnan, Parick Wagstrom, Gregor von Laszewski «GSFL: A workflow Framework For Grid Services». http://www.unix-globus.org/cog/papers/gsfl-paper.pdf [Disponible en Ligne] [87] Steve Graham, Tom Maguire, Jeffrey Frey, Nataraj Nagaratnam, Igor Sedukhin, David Snelling, Karl Czajkowski, Steve Tuecke, William Vambenepe. «Web Services Service Group Specification (WS-ServiceGroup) Version 1.0». 2004 [88] Steve Graham, Peter Niblett, Dave Chappell, Amy Lewis, Nataraj Nagaratnam, Jay Parikh, Sanjay Patil, Shivajee Samdarshi, Steve Tuecke, William Vambenepe, Bill Weihl. «Web Services Notification (WS-Notification) Version 1.0» 2004 [89] Lydia N Khelifa, Youcef Aklouf, Habiba Drias «Business Process Collaboration based on Web Service Resource Framewok» International Global Innovation Business Development (GBID2008). Rio de Janeiro. Brésil. Janvier 2008. [90] Glenn Wasson, Marty Humphrey 91

Bibliographie «Exploiting WSRF and WSRF.NET for Remote Job Execution in Grid Environments». IEEE.2005 92

Glossaire Glossaire BtoB 42 (ou B2B, pour Business-to-Business) Le commerce électronique inter-entreprise couvre un large éventail d'activités. Par exemple, les systèmes BtoB assurent l'échange de documents tels que bons de commande et factures entre des partenaires logistiques. Ils permettent également à une entreprise industrielle de mettre en œuvre une place de marché électronique (ou e-place de marché) pour consolider l'achat des matières nécessaires à sa production auprès de multiples fournisseurs. Ou encore à un distributeur d'acheter les marchandises vendues dans ses magasins. Ils peuvent jouer le rôle de places de négoce ou de "bourse" pour des produits de base, ou pour une catégorie de produits d'un type déterminé ou liés à un segment de marché particulier. Les systèmes B2B peuvent aussi automatiser les achats des matières et des fournitures consommables de l'entreprise. E-commerce. Abréviation pour commerce électronique (commande et paiement de biens par le Web). E-business. Plus large que le «e-commerce», ce terme désigne tous les processus économiques transformés par le Web : l'intégration des systèmes d'information avec les clients et les fournisseurs (via des sites web à accès réservé : les Extranets), le travail dans l'entreprise (via un site web réservé aux employés : l'intranet), le recrutement, la finance, le marketing, etc. Externalisation ou l outsourcing Une entreprise confie à un consultant ou à un fournisseur de services applicatifs la gestion de ressources informatiques internes composantes de son infrastructure, personnel, processus, applications. Elle peut ainsi se consacrer pleinement à son cœur de métier, sans se préoccuper de problèmes d informatique. Application Framework for e-business Modèle d'architecture de développement d'applications assurant l'interconnexion des processus stratégiques et couvrant différentes plates-formes. L'Application Framework for e-business comprend une série de standards et de technologies, une méthodologie puissante et des produits performants. Ce modèle applicatif 42 http://www-05.ibm.com/e-business/ch/fr/glossary/index.html 93

Glossaire repose sur une approche multifournisseur et sur des standards ouverts tels que HTML, TCP/IP, Java et XML 94

Glossaire Annexes Annexe A: Les services web. Annexe B: Le Grid Computing. Annexe C: Open Grid Services Infrastructure. Annexe D: Exemple d un service Web à état dans le WSRF.. 95

Annexe A : Les Services Web 1. Définition Annexe A: Les Services Web Le W3C a définie les Web Services comme étant «un système logiciel conçu pour supporter l interaction interopérable de machine à machine sur un réseau. Il possède une interface décrite dans un format exploitable par la machine, i.e. décrite en WSDL (Web Services Description Language). D autres systèmes interagissent avec le Web Service d une façon prescrite par sa description en utilisant des messages SOAP (Simple Object Access Protocol), avec le protocole HTTP (HyperText Transfer Protocol) et une sérialisation XML 43 au même temps que d autres normes du Web» [9]. 2. Architecture des Services Web La vision par laquelle on percevait le Web a évolué. Ainsi, nous sommes passés d'une vision dans laquelle le web était constitué d'un ensemble de pages accessibles par mots clés à une vision du Web où celui-ci devient un fournisseur de ressources accessibles par leurs contenus. La majorité des ressources du Web sont constituées de programmes et de contenus accessibles en ligne. Ainsi, la notion appelée "Web Service" est née. Ce chapitre a pour objectif de décrire les concepts de bases des Web Services. L architecture des services Web est une instance de l Architecture Orientée Service (SOA). SOA est un modèle (abstrait) qui accepte de gérer l hétérogénéité des applications en permettant à des applications ou services de communiquer et de travailler ensemble, quelque soit leurs plates-formes ou localisation. L architecture des services Web est une architecture qui définie les éléments globaux qui assurent l interopérabilité des services Web. Nous allons commencer par présenter l architecture de base utilisée pour les services web isolés et qui est composée de trois couches, pour passer ensuite à l architecture étendue ou en pile, souvent utilisée lors de la composition de services Web. Architecture de référence Comme illustré dans la figure 35. L architecture de référence des services Web se base sur ; l interaction entre trois service : l Annuaire de service (Service Registry), le Fournisseur de service (Service Provider) et le Demandeur de service (Service Requester). 43 http://www.w3.org/xml 96

Cette interaction s effectue à travers les trois opérations suivantes: Annexe A : Les Services Web La publication de la description de services, La recherche et la découverte de la description du service, L invocation du service basé sur la description. Fournisseur L enregistrement des services Invocation Interrogation Annuaire Découverte dynamique des services Figure 35 : Le fonctionnement des Web Services Cette architecture a été étendue par le W3C pour prendre en considération les protocoles de composition et pour intégrer les nouveaux standards émergeants tels que la sécurité, l administration, etc. Architecture étendue L architecture de référence a été étendue en intégrant d autres couches qui traitent la sécurité, la composition des web services... Nous pouvons distinguer dans cette architecture trois types de couches: Client Description des services découverts L infrastructure de base (Discovery, Description, Exchange) définit les composants de l architecture de base. Tel que définit dans la section précédente. La couche Processus Métier (Business Process) permet l intégration de services web. Elle présente un processus métier comme un ensemble de services Web. Il peut être décrit avec plusieurs langages tel que le BPEL..ect (voir chapitre II). Les couches transversales (Security, Transactions, Administration, QoS 44 ): ces couches rendent viable l utilisation effective des services dans le monde industriel. 44 QoS: Quality of Service. 97

Annexe A : Les Services Web Business Process BPEL4WS, BPML Discovery UDDI, Description WSDL Exchange SOAP S E C U R I T Y T R A N S A C T I O N S A D M I N I S T R A T I O N Q o S Transport HTTP, HTTPR, SMTP/MIME, FTP, Figure 36: Architecture en pile. 3. Concepts de base des Web Services Les Web Services sont décrits grâce à des fichiers WSDL (Web Service Definition Language) enregistrés dans un répertoire UDDI (Universal Description, Discovery, and Integration) et communiquent grâce au protocole SOAP. Nous décrivons chacun de ces concepts dans ce qui suit : 3.1 SOAP (Simple Object Access Protocol) Initialement, SOAP a été crée par Microsoft puis développé en collaboration avec IBM, Lotus et UserLand. SOAP (Simple Object Access Protocol), a été crée par Microsoft puis développé en collaboration avec IBM, Lotus et UserLand. SOAP est un protocole basé sur XML pour la messagerie et l appel à distance des procédures (RPCs : Remote Procedure Calls). Plutôt que de définir de nouveaux protocoles de transport, SOAP utilise: HTTP, SMTP..[10] 1) Un message SOAP : comme illustré dans la figure 37 contient les éléments suivants: Figure 37 : La structure d une enveloppe SOAP 98

Annexe A : Les Services Web Un élément enveloppe : identifie le document XML comme étant un message SOAP.Il définit le début et la fin du message (la racine du document XML contenant le message SOAP et l espace de nom). Il contient : un élément header (optionnel) : composé des attributs du message point intermédiaire ou final. un élément body (obligatoire) : qui contient toutes les informations de l appel et de la réponse. Autrement dit, le nom de la méthode invoquée par une requête ou le nom de celle pour générer la réponse. En plus, de l espace de nom correspondant au nom du service. Cet exemple illustre la structure d un message SOAP <soap:envelope smlns:soap=http://www.w3.org/2001/12/soap-envelope soap:encodingstyle=http://www.w3.org/2001/12/soap-encoding> <soap:header> </soap:header> <soap:body> </soap:body> </soap:envelope> 2) L appel à distance des procédures en utilisant SOAP : s effectue en définissant un protocole RPC incluant les différentes parties du RPC qui sont portées (identité de l objet, nom de l opération, paramètre) et qui décrivent comment s effectue le transport entre la représentation SOAP et la représentation de l application. Exemple de requête SOAP : contient une méthode GetStockPrice qui demande le prix des actions de l entreprise IBM. POST /InStock HTTP/1.1 Host: www.stock.org Content-Type: application/soap; charset=utf-8 <?xml version= 1.0 > <soap:envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope soap:encodingstyle=http://www.w3.org/2001/12/soap-encoding> <soap:body xmlns:m=http://www.stock.org/stock> <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> Exemple réponse SOAP: la réponse est contenue dans GetStockPricesResponse. HTTP/1.1 200 OK Connection: close Content-Type: application/soap; charset=utf-8 Date: Mon, 28 Sep 2002 10:05:04 GMT <?xml version= 1.0 > <soap:envelope xmlns:soap= http://www.w3.org/2001/12/soap-encoding soap:encodingstyle= http://www.w3.org/2001/12/soap-encoding > <soap:body xmlns:m= http://www.stock.org/stock > <m:getstockpricesresponse> <m:price>34.5</m:price> </m:getstockpricesresponse> 99

Annexe A : Les Services Web </soap:body> </soap:envelope> 3.2 WSDL (Web Service Definition Language) WSDL représente un format XML qui décrit l interface d un Web Service et fournit les utilisateurs avec des points de contacts [10]. Il décrit aussi les composants nécessaires au protocole SOAP et à l interaction avec un autre service. WSDL définit également les activités du Web Service appelées opérations et les données transmises appelées messages. WSDL permet de séparer la description de la fonctionnalité abstraite d un service des détails concrets d une description de service, c.-à-d. la séparation de «quelle» fonctionnalité est fournie du «comment» et «où» celle-ci est offerte. Une description WSDL définit d'abord des «types», utilisés pour former des messages, associés dans des ports et reliés à un protocole par des «bindings» formant des Services Web. Cet exemple illustre la structure fondamentale d un document WSDL. <?xml version="1.0" encoding="iso-8859-1"?> <definitions> <types> </types> <message name=>...</message> <interface name=>... </interface> <binding name=>... </binding> <service name=>... </service> </definitions> Le 26 juin 2007, le W3C a recommandé une nouvelle version : WSDL2.0. 3.3 UDDI (Universal Description, Discovery, and Integration) UDDI (Universal Description Discovery and Integration) est un standard issu de la collaboration des plus grands leaders de l industrie informatique tels que Microsoft, IBM, Sun, Oracle, SAP, Hewlett Packard, Intel, etc. L UDDI (Universal Description, Discovery and Integration) est une plate-forme destinée à stocker les descriptions des Web Services disponibles. L UDDI est à la version 3.0 qui est un standard adopté par OASIS en 2003 et permet de construire des annuaires de services publics et privés. L UDDI (Universal Description, Discovery and Integration) est une plate-forme destinée à stocker les descriptions des Web Services disponibles, à la manière d un annuaire de style «Pages Jaunes», «Pages Blanches» et «Pages Vertes». o Le système de «Pages Jaunes» (i.e. Business Service) fournit le nom de l organisation, et les informations de contact. Ce système est utilisé pour trouver un service par une taxonomie standardisée. 100

Annexe A : Les Services Web o Le système «Pages Blanches» (i.e. Business Entity) fournit des informations par catégories d entreprise et de secteur d activité dans lequel l organisation exerce, ainsi que les services offerts. Ce système est utilisé pour trouver un service par le contact, nom et adresse du fournisseur. o Le système «Pages Vertes» (i.e. Binding Template), permet d obtenir des informations techniques détaillées à propos des services et de décrire comment interagir avec les services. Ce système est utilisé pour trouver un service par les caractéristiques techniques demandées. Toutefois, un mécanisme de découverte des Web Services existe, qui ne repose pas sur l UDDI tel que le WS-Inspection 45. 4. Web Services Addressing Le responsable du domaine Architecture du W3C : Philippe Le Hégaret indique que les «Web Services Addressing 1.0 offre aux développeurs une méthode d'adressage d'objets pour les applications de services Web» et «étend les capacités des Web Services en permettant les échanges de messages asynchrones et en permettant l'interaction de plus de deux services à la fois». En 2004, les Web Services Addressing 1.0 ont été définis comme étant une nouvelle méthode standard d'adressage des objets pour les applications de services Web. Ils offrent un système indépendant du transport qui permet d'adresser les objets pour les applications de services Web, construites à partir des URIs. Cette nouvelle méthode est appelée référence d'un point d'entrée (EPR). Ce dernier, peut tenir lieu de cookie lors d'interactions de services Web en plus des fonctions d'adressage. Une autre caractéristique des EPR est ce qu'on pourrait appeler le sac de métadonnées. Ce dernier décrit des informations complémentaires à être intégrées à l'epr - que ce soit une description de capacités du point d'entrée, une description WSDL, ou des données de Web sémantique [26]. En mai 2006, le W3C 46 recommande officiellement l utilisation du Web Services Addressing (WS-Adressing) [26]. Ce dernier, se compose des spécifications Core 47 et SOAP Binding 48. L'industrie dispose maintenant d'un standard interopérable et robuste permettant l'adressage de Web Services. 45 Microsoft et IBM. WS-Inspection. www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html 46 http://www.w3.org/ 47 W3C Recommendation. Web Services Addressing 1.0 Core http://www.w3.org/tr/2006/rec-ws-addrcore-20060509/ 9 May 2006 48 W3C Recommendation. Web Services Addressing 1.0 - SOAP Binding http://www.w3.org/tr/2006/recws-addr-soap-20060509/. 9 May 2006 101

Annexe B : Le Grid Computing 1. Introduction Annexe B : Le Grid computing Le terme Grid [1] est apparu en 1990 pour dénoter une infrastructure de calcul distribué proposé pour avancer les sciences et l ingénierie. Le Grid computing [2] est une forme de calcul distribué qui inclut, des applications, des données, du stockage, ou des ressources réseaux. Ces derniers sont coordonnés et partagés à travers des organisations dispersées géographiquement. Ce chapitre comprendra la définition du Grid Computing, son architecture et une étude comparative du Grid Computing avec les systèmes Peer-To-Peer et le Web. 2. Définition La definition a été donné par I. Foster et Al dans [1] The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. Un résumé de la définition a été avancé dans [3] où le Grid a été définit comme étant un système qui coordonne les ressources qui ne sont pas sous un contrôle centralisé Le Grid Computing [8], ou calcul intensif distribué, peut se définir comme l utilisation simultanée des ressources de nombreux ordinateurs en réseau à la résolution d un même problème - généralement un problème qui nécessite une grande quantité de cycles de traitement ou l'accès à de gros volumes de données. Le Grid représente aussi un système qui utilise des protocoles et des interfaces ouverts et standards et délivre une qualité de service (QoS) non triviale [3]. 3. Architecture du Grid Computing L environnement du Grid a été développé pour répondre à un besoin en ressources. L utilisation des ressources (micro processeur, disque de stockage, programme, périphérique ect) est caractérisée par leur disponibilité en dehors du contexte du domaine local administratif. Cette approche d approvisionnement externe entraîne la création d un 102

Annexe B : Le Grid Computing nouveau domaine administratif qui n est autre que l organisation virtuelle. Nous détaillons cette architecture dans la section suivante. 3.1 L Organisation Virtuelle Dans [1], I.Foster et Al ont introduit la notion d organisation virtuelle comme suit : Flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and resources. Cette notion d un ensemble d individus et/ou d institution définis par une forme de partage de règles est appelée organisation virtuelle (OV). Les organisations virtuelles permettent à des organisations individuelles ou/et en groupe dispersés de partager les ressources d une façon contrôlée de telle sorte à ce que ces membres peuvent collaborer pour atteindre des objectifs communs. Quelques exemples concrets des organisations virtuelles sont cités dans [1] tels que : L application des services fournisseurs (Service Provider SP) ; Le stockage des services fournisseurs ; Les consultants engagés par un constructeur d automobiles pour exécuter un scénario d évaluation durant la planification d une nouvelle usine ; L utilisation des systèmes de bases de données et des systèmes de simulations par une équipe de gestion de crise pour planifier une réponse à une situation d urgence Le modèle en couche du Grid Computing Le modèle du Grid Computing est composé d un ensemble de couche tel que décrit dans la figure ci-dessous. Nous décrivons en détail chacune des couches composants le modèle. Application Collective Resource Connectivity Fabric Application Transport Internet Link Architecture du protocole d Internet Figure 38 : Les couches de l'architecture du Grid [1] (Par analogie à l architecture du protocole Internet) 103

Annexe B : Le Grid Computing A Couche Fabric : interfaces aux contrôle local Cette couche fournit les ressources pour lesquelles l accès est négocié par le protocole du Grid. Une ressource peut être une entité logique tel qu un système distribué de fichier, un système de cluster, des systèmes d ordinateurs distribués, ou encore une entité physique [4]. Cette dernière peut être un instrument scientifique, tels que les télescopes et réseaux de sonde (sensor networks), qui fournit des données en temps réel directement transmises aux sites de calcul. Les composants de cette couche [1] implémentent les opérations locales des ressources. L expérience suggère qu au minimum, les ressources doivent implémenter le mécanisme d interrogation et les mécanismes de gestion des ressources. Le mécanisme d interrogation permet la découverte des structures, des états, et des capacités de cette couche. Les mécanismes de gestion des ressources fournissent quelques contrôles de QoS délivrée. B- Couche Connectivity : communication facile et sécurisée : La couche Connectivity définit le centre de la communication et les protocoles d authentification requis pour les transactions réseaux spécifiques au Grid. Les protocoles d authentification sont construits sur les services de communication pour fournir des mécanismes cryptographiques de sécurité et pour vérifier l identité des utilisateurs et des ressources. Les protocoles de communication de cette couche permettent l échange des données entre les ressources de la couche Fabric. La communication doit inclure les protocoles de transport, de routage et d appellation (namming) [1]. Cependant, elle ne demande pas de nouveaux protocoles qui prennent en compte des types particuliers de réseau dynamique. La solution d authentification, pour l environnement des OVs, doit permettre le Single Sign On 49 (SSO), la délégation, l intégration avec des solutions diverses de la sécurité locale et la relation des utilisateurs qui est basée sur la confiance. Les solutions de sécurité pour le Grid doivent fournir un support fiable, pour la protection de la communication. C- Couche ressource : partage unique des ressources : Cette couche construite sur la communication de la couche Connectivity et les protocoles d authentification afin de définir des protocoles pour sécuriser les négociations, les 49 Single-Sign-On http://www.opengroup.org/security/sso/ 104

Annexe B : Le Grid Computing initiations, la surveillance du contrôle et le payement des opérations partagées sur les ressources individuelles. D- Couche collective : coordination des ressources multiples La couche collective, dans l architecture, comprend les protocoles et services qui ne sont associés avec aucune ressource spécifique mais sont plutôt globaux, par nature, et capture les interactions à travers les collections de ressources. E- Couche application : La dernière couche, Couche Application, de l architecture Grid comprend les applications des utilisateurs qui opèrent dans l environnement d une OV. Les applications Grid [4] sont typiquement développées en utilisant des environnements de programmation permettant la définition des interfaces, des services d ordonnancement et de brokering fournis par un médiateur au niveau de l utilisateur. Un exemple d architecture Grid Nous illustrons dans le tableau suivant un exemple d architecture Grid d une simulation multidisciplinaire décrite par I. Foster et Al dans [4] avec ses différents composants. Application Archiveur de données distribuées, coupleur de résolution spécifique (Solver coupler) Couche Découverte de ressource, ressource Brokering, système de Collective Application surveillance, autorisation de communauté, révocation de générique certificat Accès au calcul, accès aux données, accès aux informations Couche Ressource concernant la structure du système, état, performance Communication (IP), découverte service (DNS), Couche Connectivity authentification, autorisation et délégation Couche Fabric Systèmes de stockage, ordinateurs, réseaux, catalogues Tableau 1: Exemple d'une architectutre Grid 4. Le Grid Computing et le Web Les technologies du Web sont attrayantes comme plateforme pour la construction des systèmes et des applications des organisations virtuelles. Cependant, avec les modèles d interaction assez riche qui se produisent dans les organisations virtuelles, ces technologies ne répondent pas à leurs besoins. 105

Annexe B : Le Grid Computing Pour l'exemple, des navigateurs d'aujourd'hui de Web emploient typiquement Transport Layer Security (TLS 50 ) pour l'authentification, mais ne supportent pas Single Sign-On ou la délégation. Des mesures claires peuvent être prises pour intégrer des technologies de grille et de Web. Ainsi, les possibilités Single Sign-On fournies dans les prolongements du Grid Security Infrastructure (GSI) [6] à TLS, s'intègreront dans des navigateurs du Web. Les possibilités de délégation de GSI permettraient à un client du navigateur de déléguer des possibilités à un serveur web de sorte que le serveur puisse agir au nom du client. Ces possibilités, à leurs tours, facilitent les technologies d'useweb 51 pour établir les «portails de OV». Ces derniers fournissent aux clients légers un accès aux applications sophistiquées des organisations virtuelles. 5. Le Grid Computing et le P2P I. Foster et Al dans [4] décrivent le Peer-to-peer Computing (par exemple, dans Gnutella [7], Napster 52 ) et Internet Computing (par exemple par les systèmes de SETI@home, de Parabon, et d'entropia), comme étant l exemple le plus général «au delà du serveur de client» qui partage les modalités et les structures informatiques pour caractériser les OVs. Le Grid est une plateforme de calcul géographiquement distribuée comprenant un ensemble de machines hétérogènes dans lesquels les utilisateurs peuvent y accéder à travers une seule interface. Le P2P est une classe de système auto-organisationnel qui prend avantage des ressources de stockage, de calcul, d information et d humain distribués et disponibles à travers Internet. Le P2P a été popularisé en supportant deux classes importantes d application telles que le partage de fichier (Gnutella [7], Napster 53 ) et le calcul fortement parallèle dans lesquels des applications s exécutent en parallèle dans des nœuds disponibles (SETI@home, FIGHTAIDS@home). Les réseaux Peer-to-Peer (P2P) et les Grids sont des modèles de calculs distribués, qui permettent une collaboration distribuée. Ceci en intégrant des ordinateurs dans les réseaux dans lesquels chacun consomme et offre des services D. Talia et Al [5], ont présenté une synthèse qui inclut une étude comparative entre les deux systèmes émergeant selon des critères de sécurité, de découverte de ressources 50 Transport Layer Security (TLS) définit un protocole qui fournit l'intégrité des données entre deux applications communicantes. Il repose sur un protocole fiable de transport tel que le TCP. http://www.ietf.org/rfc/rfc2246.txt 51 http://www.useweb.fr/ 52 http://www.napster.com/ 106

Annexe B : Le Grid Computing Nous résumons cette étude dans le tableau suivant : Grid Computing Sécurité - Existence de communauté fermée. - Mécanisme d authentification, autorisation, intégrité et confidentialité. Connectivité - Machines puissantes connectées à travers un réseau à hautes performances et hautement disponibles. - Accès aux nœuds lent à cause de l accès aux ressources Grids lié aux mécanismes d attribution rigoureux d «accounting». Services d accès Découverte de ressources - Des services sécurisés sont fournis par Globus Toolkit 54 pour la soumission de travail par batch ou l exécution interactive des applications sur des machines distantes. - Mécanisme pour partage efficace et mouvement des données à travers les nœuds. - Découverte des ressources basée sur un modèle centralisé ou hiérarchique (Globus Toolkit). P2P - Communauté ouverte. - Pas d authentification. - Pas de validation de contenu. - Assure l anonymat et résiste à la censure. - Ordinateurs Desktop connectés via le réseau Internet disponible par un temps limité avec une fiabilité limité. - Le nombre de noeuds connectés dans un réseau P2P à un instant donné est plus grand que celui du Grid. - Ne supporte pas le mécanisme pour l allocation explicite des cycles et de stockage à distance - Fournit des protocoles pour le partage et l échange des données à travers les nœuds. - Chaque nœud notifie sa présence périodiquement au réseau en découvrant ses voisins au même temps. Tableau 2: Tableau comparatif entre Grid Computing et P2P. 54 Globus toolkit développé par des chercheurs Du Laboratoire National Argone et l université du sud de Californie USA. Un utilisateur ou une application peut directement obtenir de l information concernant des nœuds de ressources données en interrogeant un serveur d application exécutant dans ce dernier ou dans un noeud qui récupère ou publie des l information concernant un ensemble de nom d une organisation donnée car un tel système d information est construit pour accomplir les besoins des Grids basée sur l organisation http://www.globus.org/toolkit 107

Annexe C: Open Grid Service Infrastructure (OGSI) Annexe C : Open Grid Service Infrastructure (OGSI) Les principes de l Open Grid Service Infrastructure (OGSI) En juillet 2003, des mécanismes de création, de gestion, et d échange d information entre entités appelées Grid Services ont été proposées par l OGSI Working Group du Global Grid Forum (GGF) [14]. La spécification de l infrastructure Open Grid Service Infrastructure (OGSI) [14] a définit un Grid Service comme étant un Web service respectant un ensemble de conventions (interfaces et comportement) adaptées aux contraintes de l environnement Grid. Cette spécification a pour objectif de normaliser les services composant les grilles, et de garantir aussi l'interopérabilité des systèmes hétérogènes pour le partage et l'accès à des ressources de calcul, et de stockage distribuées. L OGSI a introduit la notion d état au Web Service et a défini des approches de création, et de gestion de la durée de vie d une instance de Web Service : - Pour la déclaration, la découverte des services des données d état ; - Pour la notification asynchrone de changement d état de service ; - Pour la représentation et la gestion des collections d instances de service ; - Et pour le traitement commun de l invocation par défaut du service. Les spécifications OGSI L OGSI est une norme qui a pour objectif de faciliter le développement des Web services adaptés aux contraintes spécifiques à un environnement Grid. Cette norme définit un ensemble d interfaces et comportements communs aux services susceptibles d être proposés dans le Grid. Les Grid Service sont décrits par Web Service Description Language (WSDL). Grid Web Service Description Language (GWSDL) [21] : extension du WSDL 1.1 permettant l expression de la norme OGSI. Il reste cependant une solution temporaire qui sera prochainement remplacée par le WSDL 1.2 qui devra intégrer les notions définies par GWSDL (héritage des PortType). Une base de schéma XML et la sémantique associée pour les messages WSDL pour supporter une interprétation commune. 108

Annexe C: Open Grid Service Infrastructure (OGSI) Les extensions et les conventions WSDL L OGSI se base sur les Web Services, particulièrement le WSDL comme mécanisme de description des interfaces publiques des Grid Services. Cependant, WSDL 1.1 est déficient dans deux domaines critiques : - Le manque d extension d interfaces (PortType). - L incapacité de décrire les éléments d informations additionnelles dans un PortType (manque de contenu ouvert). A la place, l OGSI définit une extension au WSDL1.1 isolé de l élément WSDL PortType, qui fournit les extensions minimales requises au WSDL1.1. Ces extensions correspondent aux fonctionnalités équivalentes agrées par le W3C Web Service Description Working Group. GWSDL rajoute de nouveaux concepts à l élément WSDL PortType. Les données de service (Service Data) L approche Web service qui a été introduite dans l OGSI, identifie le besoin pour un mécanisme commun d exposer une donnée d état de l instance de service aux demandeurs de service pour interrogation, mise à jour et changement de notification. Depuis, ce concept est applicable dans n importe quel Web Service incluant ceux utilisé en dehors du contexte des applications Grid. La désignation et les liens «Binding» Une instance de Grid service, qu elle soit volatile ou persistante, est accessible via un Grid Service Handle (GSH). Un GSH est une simple URI, et ne contient pas suffisamment d information pour permettre à un client de communiquer directement avec l instance de service. Il est donc nécessaire, avant de pouvoir utiliser une instance de service, que le GSH soit d abord résolu en un Grid Service Reference (GSR). Un GSR contient toute l information nécessaire au client pour communiquer avec l instance de service, et sa forme dépend du mécanisme de binding utilisé. Une même instance de service peut être associée à plusieurs GSR, par exemple lorsque celleci supporte plusieurs protocoles de communication. Un même GSH peut donc être résolu en différents GSR suivant le client, ou suivant le moment où le resolving a lieu. Afin de permettre au client de choisir le GSR (ou le type de GSR) qu il souhaite utiliser, plusieurs GSH, chacun associé à un seul GSR (ou un seul type de GSR), peuvent être proposés pour accéder à une même instance de service. 109

Annexe C: Open Grid Service Infrastructure (OGSI) Figure 39 : Resolver un GSH [14]. Les PortTypes du Grid Services Les opérations du Grid Service sont définies par les interfaces des Grid Services associées qui correspondent au PortType WSDL. Chacun des PortType est relié à une ou plusieurs opérations qu un client peut invoquer en échangeant une séquence de messages spécifiques avec les instances de services. Les interfaces OGSA/ WSDL PortType ont été proposées : - GridService qui définit les trois opérations FindServiceData interroge des sources d'informations au sujet de l'instance de grid service, en cherchant l'information d'introspection de base (handle, reference, primary key, home handlemap), l'information plus riche par interface, et l'information du service spécifique. Cette opération fournit un support extensible pour les différents langages d interrogation. SetTerminationTime et GetTerminationTime placer et obtenir un temps de terminaison pour une instance de grid service. Destruction des instances de service terminé. - Factory opération CreateService, qui crée une instance de Grid Service. - Registration Qui définit deux opérations: RegisterService enregistre les GSHs. UnregisterService supprime l enregistrement d un GSH. - NotificationSource permet aux clients à partir des instances de Grid Service qui implémentent les porttype, de souscrire des messages de notification. Le service qui implémente ce porttype n est pas obligatoirement une instance. [14] 110

Annexe C: Open Grid Service Infrastructure (OGSI) - ServiceGroup [14] Permet une instance de Grid service de maintenir l information d un groupe avec d autre Grid Service. Un registre Grid service peut être défini par un PortType qui étend le comportement de base décrit par servicegroup. D autres interfaces standards seront définies telles que celles de l autorisation, de la gestion de la politique, du contrôle concurrent, de la surveillance et de la gestion d un ensemble potentiel d instance Grid [17]. Relation entre WSRF et l OGSI L OGSI et le WSRF concernent la manipulation des ressources à état à travers une interface du Web Service. Les Grid Services et les WS-Resources peuvent être crées, adressés, et détruits essentiellement de la même façon. WSRF a deux avantages [13] importants relatifs à l OGSI : 1- Le WSRF exploite aussi bien les standards XML existants que les standards des Web Services émergeant (tel que le WS-Adressing). 2- Le WSRF impose une séparation claire entre les ressources à état et les processeurs de message. Reste que le WSRF fait clairement la distinction entre les interfaces des Web Services et les ressources à état fondamentales. La différence entre l OGSI et le WSRF est le mécanisme d adressage de ressources. OGSI utilise le GSH et le GSR constructs. Le GSH ne fournit pas suffisamment d information d adressage pour permettre l accès au client de l instance de service, mais il est l expression virtualisé la plus stable du service. Un service handle resolver est utilisé dans l OGSI pour resolver GSH au GSR. En revanche, WSRF construit sur le WS-Adressing pour accomplir les mêmes buts mais d une façon légèrement différente 1- Il adopte le concept du «endpoint reference : EPR» défini dans la spécification WS-Addressing comme une syntaxe XML pour l identification des points d entrées (endpoints) des web services. 2- Plutôt que de distinguer entre deux types fixes de noms (l invariant GSH et le variant GSR). Le WSRF introduit un mécanisme pour associer un resolver de service avec n importe quelle référence du point d entrée. Le WSRF étend le modèle de notification original de l OGSI en exploitant le WS-Notification. dans un environnement dans lequel les ressources à état peuvent changer leurs états dynamiquement, il devient important de fournir un support pour une notification asynchrone des changements. 111

Annexe C: Open Grid Service Infrastructure (OGSI) Dans [16], un mapping des concepts primaires de l OGSI aux composants du WSRF et WS- Notification a été illustré dans le tableau suivant : Fonction OGSI WSRF Création L opération createservice du La définition Factory pattern d une PortType Factory nouvelle entité Adresser Grid Service Reference(GSR) WS-Addressing Endpoint Reference avec l entité et Grid service handle (GSH) Reference Properties. Destruction L opération destroy du L opération Destroy du PortType Immédiate PortType du GridService ResourceLifetime. Cependant, cette opération est synchronisée dans le WS Resource Framework. Destruction Les opérations L opération SetTerminationTime du ordonnée requestterminationafter et porttype ResourceLifetime est équivalente requestterminationbefore du au «after»et«before» qui sont superflus PortType GridService en absence d ordonnancement du temps réel. Déterminer L élément CurrentTime de la Propriété de la ressource CurrentTime Le temps donnée du PortType du courant GridService. Déterminer L élément de donnée Propriété de la ressource La durée de terminationtime du PortType TerminationTime vie du GridService Notifier la destruction Non disponible Souscrire au sujet ResourceDestruction Tableau 3: Le mapping des concepts primaires de l OGSI aux composants du WSRF [16] Le but du WSRF est de simplement permettre la manipulation des ressources à état via les opérations des web services car les web services n ont ni une instance ni un état [68]. (Un exemple représentatif du WSRF est présenté dans Annexe C). 112

Annexe C: Open Grid Service Infrastructure (OGSI) Un projet intitulé Semantic Web Services Resource Framework (WSRF-S) 55 report WSMO A été lancé pour l intégration de la sémantique dans le WSRF au niveau du WS-Notification entre autres. 55 WSMO Working Draft. Semantic Web Services Resource Framework (WSRF-S) report. http://www.wsmo.org/tr/d31/v0.1/20050808/. Report WSMO. Working draft.2005. 113

Annexe D: Exemple d un service Web à état dans le WSRF Annexe D : Exemple d un Service Web à état dans le WSRF 1. Introduction Le Web Service Resource Framework (WSRF) est un ensemble de spécifications visant à décrire, à gérér les web services à état. Il représente la redéfinition du Open Grid Service Infrastrucure (OGSI) suite au nombreuses critiques des la communauté des Web services. Dans cette annexe, nous allons expliquer par l exemple le principe d un web service à état. 2. Les Web Services Sans Etat Nous allons à présent présenter un exemple 56 illustrant la nécessité et l objectif de l introduction du concept d état dans les Web Services. Figure 40: L'invocation d'un Web Service Sans Etat. La figure 40 représente l invocation classique d un web service. Ce web service est sans état, ce qui signifie qu il ne peut pas mémoriser l information ou garder l état d une invocation à une autre. L exemple ci-dessus représente un accumulateur. Cet accumulateur est initialisé à zéro. Nous voulons y additionner des valeurs. A la première invocation, 5 est rajouté et la valeur retournée est 5. Seulement à la deuxième invocation, rajouter un 6 retournera un 6 au lieu de 11 car le web service est sans état et ne garde pas en mémoire les précédentes invocations. 56 http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s03.html 114

Annexe D: Exemple d un service Web à état dans le WSRF Ainsi, les web services définis ne gardent pas l état. Certes, ce n est pas une mauvaise chose pour certaines applications telle que la météo. Seulement, dans l environnement Grid et dans d autres applications, cette notion est très importante. Le but à travers le WSRF est d arriver à obtenir la figure suivante. Figure 41: L'invocation d'un web service à état. L approche «Ressource à Etat» L approche proposée à travers le WSRF est de séparer l état du Web Service. L état sera sauvegardé dans une entité séparée appelée ressource. Chaque ressource aura une clé unique pour qu une interaction à état d un web service avec une ressource particulière soit identifiée. Ainsi le web service pourra interagir avec plusieurs ressources, comme illustrée dans la figure suivante. Figure 42: L'approche de ressource pour l'état Le client veut rajouter la valeur 5 à la ressource (voir figure 42). Le web service reçoit la requête de rajout sur la ressource C. Cette ressource sera enregistrée en mémoire secondaire 115

Annexe D: Exemple d un service Web à état dans le WSRF ou même dans une base de données. Les ressources peuvent être de différents types par exemple fichier. Le client peut spécifier la ressource souhaitée avec une URI (Unified Resource Identifier), seulement ce n est pas suffisant pour adresser un Web Service. Ainsi le WS-Addressing qui fournit un moyen persistent comparé aux URIs, est utilisé pour l adressage des Web Services. Ainsi, une paire de Web Service et une ressource est appelé WS-Resource et l adresse de celle-ci est appelée EPR (Endpoint Reference). Figure 43: WS-Resource. La figure 43 démontre (Filename, Size, Descriptors) représentent des propriétés de la ressource définie dans le WS-ResourceProperties. Les WS-ResourceProperties sont désignés dans la description de l interface WSDL du Web Service. Le WS-ResourceProperties est l une des spécifications du WSRF, qui comporte un certain nombre de spécification comme présenté dans le chapitre III. 3. Conclusion L exemple présenté dans cette annexe, illustre le concept de Web Service à état. Le besoin de modéliser et d intégrer la notion d état dans les Web Services a été ressenti dans le développement d applications de grandes envergures utilisées pour le Grid, dont la durée d exécution est longue. 116