Contact SCD Nancy 1 : [email protected]

Transcription

1 AVERTISSEMENT Ce document est le frut d'un long traval approuvé par le jury de soutenance et ms à dsposton de l'ensemble de la communauté unverstare élarge. Il est soums à la proprété ntellectuelle de l'auteur. Cec mplque une oblgaton de ctaton et de référencement lors de l utlsaton de ce document. Toute contrefaçon, plagat, reproducton llcte encourt une poursute pénale. Contact SCD Nancy 1 : [email protected] LIENS Code de la Proprété Intellectuelle. artcles L Code de la Proprété Intellectuelle. artcles L L

2 Département de formaton doctorale en nformatque UFR STMIA École doctorale IAEM Lorrane Décentralsaton des procédés méters : qualté de servces et confdentalté THÈSE présentée et soutenue publquement le 8 septembre 2008 pour l obtenton du Doctorat de l unversté Henr Poncaré Nancy 1 (spécalté nformatque) par Ustun YILDIZ Composton du jury Rapporteurs : Chhab Hanach Professeur, Unversté Toulouse I, France Heko Ludwg Drecteur de Recherche, IBM Almaden Research Center, États-Uns Examnateurs : Isabelle Chrstment Professeur, Unversté de Nancy I, France Claude Godart Professeur, Unversté de Nancy I, France Thomas Tamser Chef de Projet, CRP Gabrel Lppmann, Luxembourg Laboratore Lorran de Recherche en Informatque et ses Applcatons UMR 7503

3 Ms en page avec la classe thlora.

8

9 Remercements Je remerce vvement les rapporteurs qu se sont ntéressés à mon traval, et qu me font l honneur de partcper à ce jury, malgré leurs lourdes tâches. Je remerce Monseur Heko Ludwg qu a accepté d être rapporteur de ma thèse. Sa longue expérence sur la geston des procédés méters le désgnat tout naturellement pour évaluer mon traval, et sa lecture crtque a contrbué à l améloraton du manuscrt. Je lu en sus très reconnassant. Je tens à remercer Monseur Chhab Hanach dont j a toujours apprécé la qualté de ses travaux. Il s est nvest sans retenue dans la relecture du manuscrt. Il a le meux ressent la dffculté qu l y a à présenter un traval de recherche de qualté et m a soutenu auss ben moralement que scentfquement. Je remerce Madame Isabelle Chrstment qu m a fat l honneur de présder ce jury. Je tens tout partculèrement exprmer ma grattude à Monseur Claude Godart, pour sa confance et son amté. Il s est nvest sans retenue dans la correcton de ce manuscrt. Une thèse est autant le résultat d un traval ndvduel que de l envronnement dans lequel elle s est effectuée. Pour cela, je tens à assocer à ces remercements, tous mes collègues du LORIA et du ECOO qu m ont encouragé et adé à fnr ce traval. Je pense partculèrement à Rém, Yannck, Laszlo, Sahb, Gérald, Clauda, Adnène, Khaled, Jesse et Wald. Je remerce le FNRS du Luxembourg pour le fnancement des 3 premères années de ce traval en relaton avec le CRPGL.

10 v

11 Table des matères Chaptre 1 Introducton Chaptre 2 Problématque générale et objectfs de la thèse Introducton Contexte de la thèse Problématque Un exemple de motvaton smple Objectfs de la thèse Idées centrales de la thèse Les grandes lgnes de la démarche Contrbutons de la thèse Synthèse Chaptre 3 Etat de l art Introducton L approche orentée servce et ses technologes : Le dogme Pourquo et comment employer l approche orentée servce? Technologes relatves basées sur XML La composton des servces Synthèse sur l approche orentée servce Systèmes d nformaton décentralsés et par-à-par Pourquo avor des systèmes décentralsés? Quels sont les défs et les lmtatons des systèmes décentralsés? Synthèse sur les systèmes décentralsés par-à-par Worflow La modélsaton des procédés méters v

12 Table des matères L ntatve Workflow Worklow centralsé versus décentralsé Autres travaux lées Synthèse sur le workflow décentralsé Synthèse et stuaton par rapport à d autres approches de la problématque Chaptre 4 La modélsaton d un procédé et sa décentralsaton par défaut Introducton Le modèle du procédé Éléments caractérstques du modèle proposé et hypothèses prélmnares Exemple llustratf Défnton formelle Prncpes de décentralsaton et l orgnalté de l approche La décentralsaton d un procédé centralsé Les algorthmes pour la producton des fragments coopérants Vue d ensemble et présentaton ntutve des algorthmes Notatons Interconnexon avec les actvtés de postset et de postset étue Interconnexon avec les actvtés de preset et de preset étue Synthèse Chaptre 5 Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Introducton Contrôle du flux d nformaton Vue d ensemble et présentaton ntutve de la démarche adoptée Représentatons formelles Poltques du flux d nformaton d un servce Poltques du flux d nformaton d un concepteur Poltques du flux d nformaton contextuelles Tratement des poltques du flux d nformaton Vérfcaton des poltques Établssement des chemns fables entre les servces Producton des procédés coopérants Valdaton de la producton des procédés coopérants Synthèse v

13 Chaptre 6 L mplémentaton du chox dynamque et décentralsé des servces Introducton Chox dynamque et décentralsé de servces Exemple de motvaton et vue d ensemble Aspects formels du chox dynamque et décentralsé Chox concurrent de servces Chox dynamque par défaut Déploement des procédés coopérants à travers les dépances de chox Extenson de l approche par des consdératons d mplémentaton Chox dynamque et décentralsé retardé Synchronsaton explcte de servces Implémentaton du chox dynamque et décentralsé dans WS-BPEL Synthèse Chaptre 7 Mse en œuvre Introducton L mplémentaton de l échangeablté des procédés coopérants Implémentaton des servces La producton des procédés coopérants avec WS-BPEL Synthèse Chaptre 8 Conclusons et perspectves Rappel du contexte et des objectfs de la thèse Blan des contrbutons Perspectves Annexes Annexe A Le tratement des procédés WS-BPEL Annexe B La recherche de chemn par le tratement des poltques du flux d nformaton v

14 Table des matères Annexe C La preuve du théorème de l exacttude Bblographe 177 v

15 Table des fgures 2.1 Un exemple de motvaton La fgure(a) s agt de l utlsaton d un servce classque, l opératon du servce est évoquée par un message du clent. La fgure(b) llustre un servce qu mplémente notre approche, l est évoqué par un procédé qu sera exécuté par le servce L applcaton de l approche au procédé de l exemple de motvaton Les exemples de technologes et de standards des servces Web Exemple d orchestraton Evoluton des efforts de standardzaton Exemple de chorégraphe Les topologes des systèmes décentralsés P2P La comparason de l approche centralsée et décentralsée Le cycle de ve d un procédé [van der Aalst2005] Un exemple de workflow en BPMN La transformaton d un modèle de procédé arbtrare en un modèle structuré en deux étapes [Lu and Kumar2005] Un exemple de procédé L exemple de Global Soundness [van der Aalst1999] L élmnaton des chemns morts dans une exécuton centralsée Une dépance de contrôle entre deux actvtés qu évoquent des servces dfférents L exemple de dépance de donnée sur un chemn de contrôle Un exemple de fragment où deux actvtés sont relées par une dépance de donnée Un exemple de fragment où deux actvtés sont relées par une dépance de donnée Les exemples d actvtés nfluencées par le DPE Les dépances qu appartennent à a F,a Les dépances qu appartennent à a D,F,a Les dépances qu appartennent a F Les dépances qu appartennent à a D,F Les cas prncpaux qu dovent être consdérés en fournssant les fragments de procédés La structuraton des actvtés de connexons concernant les messages de contrôles à envoyer vers les procédés qu exécutent a 2 et a La structuraton des actvtés de connexons concernant les messages de contrôles pour satsfare l élmnaton des chemns morts x

16 Table des fgures 4.17 La structuraton des actvtés de connexons concernant les messages de contrôles pour nformer les procédés qu sont susceptbles d exécuter des actvtés de connexons pour recevor des données envoyées par les autres procédés La structuraton des actvtés de connexons concernant les messages de contrôles pour nformer les procédés qu ncluent les actvtés qu dovent utlser les sortes des actvtés que l élmnaton des chemns morts n nfluence pas La structuraton des actvtés de connexons concernant la récepton des messages de contrôles pour la suspenson ou l actvaton de l actvté a La structuraton des actvtés de la fgure4.19 par rapport à l actvé termnale du fragment ã La structuraton des actvtés de connexon qu reçovent les messages de suspensons des actvtés sources des dépances de données de l actvté a La structuraton des actvtés de connexon qu reçovent les messages d exécuton pour les actvtés sources des dépances de données de l actvté a 19 et les actvtés de connexon qu reçovent les données de procédés des actvtés a 12 et a Vue d ensemble de la méthodologe du contrôle du flux d nformaton Vue d ensemble du tratement des poltques pour la vérfcaton de l adéquaton des poltques et des nteractons Exemple de motvaton pour le contrôle du flux d nformaton Les fragments coopérants qu permettent le routage de la sorte (PB1 1 et P B2 1 ) Les fragments coopérants PBanque2 et P Banque Les fragments coopérants des servces Hôptal et Inspecteur2, (PHôptal et P Inspecteur2 5.7 Les structures algèbrques et leur dépances Le chox dynamque centralsé (a) et décentralsé (b) Les dépances de chox dynamque et décentralsé Cas 1 : La sélecton du servce s 17 qu exécute a Cas 2 : La sélecton du servce s 3 qu exécute a Cas 3 : La sélecton du servce s 3 nvoqué par les actvtés a 9 et a La chox du servce s 19 nvoqué par l actvté a Le chox du servce s x qu exécute l actvté a La synchronsaton des servces pour le chox dynamque des servces La synchronsaton mutuelle des servces dynamquement choss Le chox retardé du servce s 12 nvoqué par l actvté a La synchronsaton des servces s 2 et s La synchronsaton des servces s 4, s 5 et s La synchronsaton des servces s 4, s 5 et s La synchronsaton des servces s 7, s 8 et s La synchronsaton des servces s 7, s 9 et s Implémentaton du chox dynamque dans WS-BPEL Vue d ensemble de l mplémentaton d un servce Vue d nsemble de l ActveBPEL et les modules que nous avons étus Vue d ensemble du module PPP Les classes prncpales du module PPP x

17 Chaptre 1 Introducton Ces 20 dernères années qu ont vu les scences et technologes de l nformaton et de la communcaton (STIC) révolutonner la socété, une des applcatons sgnfcatves en est le Web qu est un moyen de rre toutes les connassances humanes accessbles à tous. C est un des plus beaux challenges qu sot, qu modfe la ve de chacun de manère essentelle. A l époque, la vson orgnelle de Tm Berners-Lee, nventeur du Web et présdent du W3C (World Wde Web Consortum), état celle d une ressource qu permettrat la collaboraton. Aujourd hu, quand on pense au futur, on peut estmer que le Web sera partout, encore plus qu aujourd hu. Les systèmes échangeront smplement entre eux de l nformaton. Nous pourrons poser à notre table de nut des questons comme : Où a-je lassé mes lunettes? Ce yaourt est-l encore mangeable? Où ma flle se trouve-t-elle? Le Web a été l une des avancées les plus vsbles de l nformatque de ces dernères années. Avec l avènement des outls portables, communquant sans fl, et embarquant des ressources de calcul de plus en plus mportantes, ans que la généralsaton de la géolocalsaton, nous pouvons prédre que chaque apparel du quotden devra non seulement un récepteur potentel de l nformaton dsponble sur le Web mas également un émetteur. Avec une évoluton de l nformatque ubqutare, ans que la mse en place de grandes bases de données représentant l nformaton à l échelle du monde enter, nous pouvons auss prédre que chacun pourra contrbuer et enrchr en permanence cette représentaton vrtuelle du monde fourne par le Web. La recherche qu porte sur le Web est un domane de recherche à part entère qu suscte beaucoup d ntérêt de la part de chercheurs de communautés très varées depus plus d une dzane d années (la premère conférence World-Wde Web fut organsée en 1994). Après une phase de boullonnement un peu rrégulère due à un fort engouement, les fls rouges de cette nouvelle pste de l nformatque se sont rapdement structurés. Actuellement, un de ces fls rouges est clarement les Archtectures Orentées Servces (AOS). Les archtectures orentées servces, et en partculer les servces Web, permettent l accessblté, la découverte et l utlsaton unverselle de n mporte quel applcaton logcelle sur le Web en utlsant des normes ouvertes. Ans, les logcels codés dans dvers langages de programmaton et sur dverses plateformes d exécuton peuvent employer des servces Web pour échanger des données à travers le Web. Il est à noter que les servces Web portent sur la défnton unverselle des nterfaces des applcatons logcelles et le format des communcatons avec ces derners. En conséquence, les servces Web n ntrodusent pas de contrantes d mplémentaton pour les applcatons qu sont rues accessbles sur le Web. Une des rasons de l ntérêt porté aux AOS est le contexte actuel de l évoluton des entreprses qu est caractérsé par une concurrence économque planétare et un envronnement sauvage, souvent mprévsble en termes de besons et de demandes du marché. Pour survvre dans un tel 1

18 Chaptre 1. Introducton contexte, les entreprses dovent être flexble, réactve et dynamque et pour ce fare, le Web leur fournt un ntergcel sans précédent. Grâce aux servces Web, les entreprses peuvent encapsuler leurs procédés méters et les publer comme des servces, chercher et souscrre à d autres servces et échanger des nformatons au-delà des frontères des entreprses. L approche des servces Web promet d être la technologe clé pour automatser les nteractons Busness-2-Busness (B2B) ans que Busness-2-Consumer (B2C). La contreparte des avantages des AOS est l extrême complexté de concepton des applcatons orentées servces. Les premères applcatons orentées servces opératonnelles ont vu le jour l y a plus de 5 ans. Elles n étaent en fat que de smples applcatons répartes du style clent-serveur qu utlsaent des formats spécaux pour nvoquer des composants dstants. Ben que la valeur de la technologe des servces de Web at été démontrée dans la pratque à l ade des applcatons plotes, l y a un désr ntense d employer cette approche pour adresser des problèmes plus généraux. Les chercheurs recherchent les perfectonnements qu élèvent le nveau et la portée de l nteropérablté au delà de ce que permet l échange de base de messages, exgeant l appu pour l nteropérablté des servces de plus haut nveau d nfrastructure. Actuellement, les descrptons des servces Web de seconde génératon sont de plus en plus rches contrarement au Web tradtonnel que nous consdérons comme syntaxque pusque seule la structure, le contenu superfcel, et les proprétés élémentares de l nformaton y sont dsponble. Ben que la technologe des servces Web ne sot pas la seule manère pour réalser une AOS, elle est la technologe la plus consdérée par l ndustre. Avec les servces Web, l ndustre adresse encore une fos le déf fondamental de l nformatque réparte : comment fournr une manère unforme pour décrre des composants ou des servces dans un réseau, les localser, et y accéder. L ndustre aborde ce problème en utlsant des standards ouverts défns en assocaton avec de larges consortums tels que le W3C et l organsaton pour l avancement des normes structurées de l nformaton (OASIS) [Dumas and Fauvet2006]. Un des ponts forts de la culture du Web est d assurer une nteracton très fructueuse entre les éléments décentralsés. Les gros problèmes de l nteracton ne sont pas seulement technques mas ce sont auss des problèmes de socété : je dspose des servces Web nécessares pour termner mon procédé, est-ce que je peux utlser ces deux servces ensembles? Est-ce qu ls exgent une nteracton drecte entre eux ou ben je peux les coordonner mo-même? S je les lasse travaller entre eux pour mo, peut-l y avor des conséquences contre mes ntérêts? Est-ce qu ls peuvent fare des chox pour mo s je ne sus pas accessble? Dos-je surveller l nteracton de ces servces en permanence? Les nteractons sont souvent formalsées sous forme de procédés méters exécutés par une organsaton d une manère centralsée ou ben par un ensemble d organsaton d une manère décentralsée. Dans de nombreuses stuatons crtques, l est nécessare d assurer un certan degré de prépondérance entre ces deux modaltés d nteractons. Les crtères qu gouvernent les nteractons sont nombreux allant de la cohérence des nteractons mutuelles à l mplémentaton des nteractons en adéquaton avec les relatons de confance des organsatons. Les avancements dans les efforts de standardsaton coïncdent avec l émergence des nouvelles exgences en termes de contrôle des nteractons des servces autonomes. Notre traval se place à l ntersecton de ces deux contextes : les efforts de standardsaton et les besons de confguraton des servces composés qu sont régs par une multtude de besons à mesure de la maturaton de leur problématques. Dans ce cadre, le traval présenté dans cette thèse porte sur la défnton et la mse en œuvre d une méthodologe de geston de procédés méters destnés aux nouvelles exgences engrées par l AOS. Dans les grandes lgnes, l objectf vsé est de fournr un envronnement d exécuton de procédés méters orenté servces qu permet à un servce, non seulement d être composé au sen d un procédé méter, mas auss de pouvor établr des nteractons sophstquées égal-à-égal 2

19 restrentes par des crtères dvers. Cette motvaton est concrétsée par la producton et le déploement des procédés coopérants exécutés par les servces composés. Ces derners spécfent les nteractons que les servces dovent établr. Cette approche permet aux servces composés de se comporter dfféremment pour chaque composton qu ls font parte. En utlsant une approche délbérément formelle, la producton des procédés coopérants se fat à partr d une spécfcaton centralsée de la composton qu est consdérée comme une descrpton de workflow. Par la sute, la méthode de producton des procédés coopérants ntègre alors, sous formes d aspects non fonctonnels tels que les poltques du flux d nformaton, les restrctons qu gouvernent les nteractons des servces composés. L exécuton décentralsée du procédé avec les procédés coopérants produts après le tratement des poltques du flux d nformaton, montre la fasablté des compostons qu ne peuvent pas être exécutées par des conceptons centralsés tradtonnels. La dernère dmenson de la méthodologe de décentralsaton fournt un support pour le déploement dynamque et décentralsé des procédés coopérants. La réalsaton de l approche développée consste à mplémenter le déploement des procédés produts vers les servces composés. Cec consdère une mplémentaton de servce alternatve aux mplémentatons actuelles. L approche résde dans l utlsaton des standards pour la spécfcaton et l mplémentaton des compostons. Car les standards fournssent, non seulement un support pour l nteropérablté des applcatons, mas auss un envronnement pour l écheangéablté (la moblté) des spécfcatons codées en standards entre les servces. Organsaton du manuscrt Ce manuscrt se présente en 8 chaptres. Quelques annexes complètent le corps du texte avec notamment la prse en compte de détals de réalsatons logcelles. Chaque chaptre commence par une ntroducton qu présente le propos et l organsaton de son contenu. En outre, une secton de synthèse résume les contrbutons, l ntérêt, les dfférences par rapport aux travaux relatfs, et les lmtatons du traval présenté dans le chaptre. Les paradgmes, les concepts, les structures, et les algorthmes sont explqués sur des exemples typques pour mettre en évdence la dffculté des problèmes qu ls formalsent et les voes pour les résoudre. Le chaptre présent, Introducton, présente rapdement le contexte général. Le chaptre 2, Problématque générale et objectfs de la thèse, est consacré à une présentaton du contexte de notre traval et de la problématque générale de la thèse. Après une ntroducton au domane de l ngénere des procédés méters, les concepts approprés du domane de recherche sont brèvement explqués. Par la sute, les problèmes prncpaux de la thèse sont clarement posés : comment fournr les procédés qu dovent être exécutés par les servces composés afn d établr des nteractons égal-à-égal? quelles sont les restrctons qu gouvernent les nteractons des servces du pont de vue des flux d nformaton à respecter? quelles sont les restrctons archtecturales à respecter? Comment un procédé coopérant peut être déployé vers un servce? Un exemple llustratf est ntrodut pour faclter la compréhenson de la problématque. Le chaptre résume également les dées centrales, l approche et les contrbutons prncpales de la thèse. Le chaptre 3, État de l art, est dédé au parcours de la lttérature relatve à notre traval 3

20 Chaptre 1. Introducton dans l objectf de présenter un état de l art. Le rôle de ce chaptre, en permettant une ntroducton progressve des paradgmes, des concepts et des technologes par rapport aux défntons habtuelles dans le domane, est essentellement pédagogque. Une analyse crtque montre leur ntérêt et leur lmtes respectfs ans que leur caractère complémentare. Compte tenu du fosonnement actuel du domane, l est névtable que l état de l art ne trate pas de manère exhaustve l ensemble des travaux réalsés. Néanmons, l analyse fate couvre rasonnablement ben les prncpaux travaux pertnents, que ce sot en matère d archtectures et de technologes de servces, de paradgmes et de modèles décentralsés et de workflow. Plus précsément, l état de l art est présenté en tros sectons. Une premère secton présente les paradgmes de servce, pusque l utlsaton des spécfcatons standards pour les servces est consdérée comme centrale dans la thèse, examne la dversté de ces paradgmes et des approches prncpales à la problématque de composton des servces. La deuxème secton de ce chaptre porte sur l étude des paradgmes et à des systèmes décentralsés et égal-à-égal. Elle fat une comparason crtque des systèmes centralsés, des systèmes hybrdes et des systèmes totalement décentralsés. Elle examne auss les approches contradctores en mettant en avant les avantages et les lmtatons au nveau de la concepton et de la mse en œuvre, et en émettant les besons que dovent satsfare les procédés méters et les compostons de servces. Enfn, ce chaptre s ntéresse à l ntatve workflow qu est l émergence nformatque la plus générale du concept de procédé, et qu est auss à l orgne de l orchestraton des servces en commençant de façon un peu hstorque, et très rapdement, par la geston décentralsée de workflow. Nous termnons cette secton par un tableau qu synthétse les caractérstques de chacune des propostons de geston décentralsée de workflow. Le chaptre 4, La modélsaton d un procédé et sa décentralsaton par défaut, décrt le cœur du traval de thèse sous la forme d une technque de décentralsaton d une spécfcaton de procédé centralsé qu compose un ensemble de servces en un ensemble de procédés coopérants exécutés par les servces. Les procédés coopérants mettent en œuvre la sémantque centralsée comme nteractons d égal-à-égal entre les servces composés. Dans un contexte de workflow, une premère parte approfondt les types de stuatons et les dépances correspondantes que la technque de décentralsaton dot trater. Une seconde parte présente les algorthmes employés. D abord, les contours du modèle de procédé qu est utlsé dans ce chaptre et le reste de la thèse sont clarement dentfés. Les hypothèses concernant l nfrastructure de communcaton sousjacente et les procédés tratés sont présentées. Les structures de données et les algorthmes sont accompagnés des exemples de motvatons qu facltent leur compréhenson. Le chaptre dscute également la complexté et les lmtatons des technques présentées. L approche présentée est une soluton relatvement complète aux problèmes de la producton de procédés coopérants à partr d une spécfcaton centralsée. Elle consdère la décentralsaton des dépances de contrôles, de données, et conversatonnelles qu nécesste une consdératon plus profonde qu une approche ntutve. Par rapport aux travaux lés à l mplémentaton de la geston décentralsée de procédés méters qu portent sur la proposton des modules et de protocoles partculers employés par les servces, l approche présentée consdère le problème de décentralsaton du pont de vue de la producton de procédés coopérants. En conséquence, les résultats du chaptre, qu seront suvs par les consdératons archtecturales correspondantes dans le chaptre 7, sont la contrbuton postve à une geston décentralsée, unverselle et peu coûteuse des procédés. Le chaptre 5, Contrôle du flux d nformaton :Vers un modèle décentralsé effcace, met les contrbutons du chaptre précédent dans un contexte nter-organsatonnel plus applcatf. Le problème dont nous souhatons nous affranchr est essentellement l adaptaton de l approche orgnale aux restrctons secondares qu gouvernent les nteractons des servces 4

21 composés. Les restrctons que nous ntéressent concernent le contrôle du flux d nformaton. Le contrôle du flux d nformaton est une dmenson essentelle des compostons effcaces de servces qu ont des nteractons restrentes du pont de vue des poltques de sécurté, d ntmté ou de confance. Il consste à spécfer et à confgurer les nteractons de servces en consdérant la propagaton de l nformaton dans la composton qu les utlse. Les contrbutons présentées dans ce chaptre nécesstent la compréhenson et l ntégraton d aspects qu sont souvent étudés séparément comme le contrôle d accès, la geston de la confance, ou la vérfcaton d une descrpton de chorégraphe. Dans un premer temps, nous développons un support pour la spécfcaton des poltques du flux d nformaton et les algorthmes pour trater celles-c. Le résultat du tratement des poltques de flux d nformaton est caractérsé par les chemns fables au sen des servces composés. Par la sute, nous ntégrons les chemns trouvés à la producton des procédés coopérants en révsant l approche présentée dans le chaptre précédent. Soulgnons qu l n est pas toujours auss évdent de donner un énoncé ntal, une défnton de ce type de restrctons. De par son caractère novateur, le contrôle du flux d nformaton selon cette approche permet une concepton progressve d une exécuton décentralsée face aux restrctons prncpales qu gouvernent les nteractons, et, faclte le passage d une spécfcaton à une exécuton. Le chaptre 6, La réalsaton des exécuton décentralsées avec le support pour le chox dynamque et décentralsé des servces, s ntéresse au chox dynamque et décentralsé des servces dans un contexte de composton décrt par les contrbutons précédentes. Le chox dynamque et décentralsé des servces sont des préoccupatons majeures dans les applcatons pervasves. Nous entons par chox dynamque et décentralsé, le chox retardé d un servce par un autre servce juste avant son nvocaton. Ce type de chox de servce profte des avantages nhérents aux systèmes décentralsés. Pourtant, le chox dynamque des servces peut engrer des problèmes de synchronsaton entre les servces choss d une manère concurrente et décentralsée. Ce chaptre dscute le chox dynamque et décentralsé des servces et fournt une soluton compréhensble aux problèmes de synchronsaton lés. La soluton proposée consste à défnr des dépances entre les actvtés et les servces de telle sorte que le chox d un servce par un autre ne cause pas des problèmes de synchronsaton dans les étapes successves de l exécuton. Contrarement aux deux chaptres précédents qu se concentrent sur les aspects concernant les nteractons des procédés coopérant, la contrbuton de ce chaptre porte sur les problèmes lés au déploement des procédés produts. Ans, une autre dmenson de la décentralsaton est étudée. Le chaptre 7, Mse en œuvre : Des mplémentatons références, présente les réalsatons logcelles du traval. Dans ce cadre, l mplémentaton consdère deux réalsatons logcelles séparées mas complémentares. La premère réalsaton consste à une mplémentaton de servce, dte de référence, qu permet le déploement d un procédé vers un servce par un autre servce clent. Elle se base sur l mplémentaton des opératons d admnstratons du moteur ActveB- PEL comme les opératons de l nterface du servce permettant ans leur nvocaton par des clents. Comme nous l avons supposé au début de notre traval, par rapport aux solutons exstantes concernant la geston décentralsée du workflow, cette mplémentaton est la preuve de l exstence d une soluton smple et élégante en explotant les apports de la standardsaton. La deuxème réalsaton logcelle porte sur l mplémentaton des algorthmes générques développés. Le langage de procédé chos est WS-BPEL qu est le standard de fat de l ndustre. Le derner chaptre, Conclusons et perspectves, rappelle les objectfs de la thèse ans que les résultats obtenus. Il content également des perspectves dans des pstes en plen développement. 5

22 Chaptre 1. Introducton 6

23 Chaptre 2 Problématque générale et objectfs de la thèse Sommare 2.1 Introducton Contexte de la thèse Problématque Un exemple de motvaton smple Objectfs de la thèse Idées centrales de la thèse Les grandes lgnes de la démarche Contrbutons de la thèse Synthèse Introducton Dans ce chaptre, nous présentons le contexte de notre traval et la problématque générale de la thèse. Après une ntroducton au domane de l ngénere des procédés méters, les concepts approprés du domane de recherche sont brèvement dscutés. Par la sute, les problèmes prncpaux de la thèse sont clarement posés. Un exemple llustratf est ntrodut pour faclter la compréhenson de la problématque. Le chaptre résume également les dées centrales, l approche et les contrbutons prncpales de la thèse. 2.2 Contexte de la thèse Le contexte général de cette thèse est l ngénere des procédés méters. Un procédé méter est une procédure qu systématse l organsaton et la poltque d une organsaton (ex. une entreprse) dans le but d attendre les objectfs ben précs de cette dernère. Cette défnton n est n smple n unque. On peut dstnguer pluseurs types de procédés qu peuvent exster au sen des organsatons : les procédés créatfs tels que les procédés de concepton d objets sophstqués ou d édton collaboratve, les procédés automatques tels que les chaînes de producton sans nterventon humane, les procédés nteractfs qu supportent les nteractons homme-homme etc. L ngénere des procédés méters peut être défne comme une branche de l nformatque qu 7

24 Chaptre 2. Problématque générale et objectfs de la thèse vse à gouverner le cycle de ve d un procédé : l s agt de le défnr d une manère formelle, fournr un envronnement d exécuton pour l exécuter, amélorer son aglté et observer sa performance. Les procédés qu nous ntéressent dans cette thèse sont structurés autour de l approche workflow[leymann and Roller2000]. Les concepts et les technologes de workflow sont ntroduts comme un ensemble de technques et outls permettant la défnton et l exécuton (et donc l automatsaton) des procédés méters. Dans de tels systèmes, un procédé est généralement perçu comme un ensemble d actvtés effectuées au sen de l organsaton. Le workflow défnt les flots de contrôle et de données du procédé. Il ntègre à la fos les acteurs humans et les systèmes logcels de l organsaton pour les orchestrer au sen du procédé. L ngénere des procédés méters, basée sur le workflow ou non, consttue aujourd hu un enjeu stratégque pour les organsatons commercales. Les problèmes sous-jacents lés à l analyse, la modélsaton, l exécuton et le contrôle des procédés méters ont fat l objet de nombreuses recherches ces dernères années pour répondre aux besons crucaux dans la pratque. Un de ces aspects est que le procédé méter d une entreprse est souvent connecté aux procédés méters d autres organsatons. Ces procédés sont souvent appelés des procédés nterorgansatonnels. L avènement des nfrastructures réseaux et des technologes standardsées du Web pousse aujourd hu les organsatons à utlser les procédés des autres organsatons et à rre leur procédés accessbles aux autres. Ce contexte actuel de l évoluton des organsatons est caractérsé par une concurrence économque devenue planétare et un envronnement agressf et souvent mprévsble en termes de besons et de demandes du marché. Les efforts de standardsaton dans ce contexte ont perms l émergence des servces Web comme support concret au développement des procédés méters nter-organsatonnels. Un servce Web est une applcaton logcelle conçue pour supporter les nteractons machnes à machnes sur le Web. Les servces Web sont basés sur l utlsaton de normes ouvertes encodées en XML[Curbera et al.2002]. Une défnton plus précse peut nclure l usage exclusf de WSDL[Chnnc et al.2002] pour la descrpton de l nterface d un servce et l usage de SOAP[Box et al.2000] pour le tratement des messages. Par rapport à d autres technologes conçues pour le développement d applcatons dstrbuées telles que Java RMI[jav], l avantage majeur des servces Web et qu ls n mposent aucune contrante de programmaton spécfque pour aux applcatons rues accessble sur le Web. De ce fat, les servces Web répondent à un des aspects essentels de la problématque ben connue de l ntégraton des données[halevy et al.2006]. Ben qu l y at pluseurs avantages qu explquent leur adopton rapde, les caractérstques des servces Web posent de nombreuses problèmes. Outre les problèmes technques de communcaton, pour lesquels les technologes des servces Web exstent, de nombreux problèmes de géne logcel persstent pour l utlsaton des servces Web : quel est le coût d utlsaton de ce servce? Pusse-je l utlser? Pour comben de temps? Je dspose des servces nécessares pour termner mon procédé, est-ce que je peux utlser ces deux servces ensembles? S je peux les utlser, est-ce qu ls exgent une nteracton drecte entre eux ou ben je peux les coordonner mo-même? S je les lasse travaller entre eux pour mo, peut-y-l avor des conséquences contre mes ntérêts? Est-ce qu ls peuvent fare des chox pour mo s je ne sus pas accessble? Dos-je surveller ce servce en permanence? En conséquence, l est pertnent de consdérer un procédé nter-organsatonnel orenté servce comme étant consttué de deux nveaux problématques : un nveau communcaton qu concerne les technologes sous-jacentes utlsées comme par exemple le format des messages échangés ou la représentaton de l nterface et un nveau applcaton méter qu concerne le chox des servces à utlser et leur combnason en foncton de dfférentes crtères. Les contrbutons de cette thèse portent plutôt sur ce derner pont tout en pensant aux relatons avec les aspects de communcaton sous-jacents. Plus précsément, nous nous ntéressons aux aspects applcatfs des procédés méters nter-organsatonnels orentés servces. Dans 8

25 2.2. Contexte de la thèse ce contexte, notre traval est placé à l ntersecton des pstes de recherche et des technologes suvantes : Servces et technologes Web La réalsaton des procédés méters nter-organsatonnels s appue aujourd hu de plus en plus sur des technologes standardsées du Web telles que les servces Web. Il est à noter que les efforts de standardsaton ont permt l émergence des standards de bases (ex. WSDL, SOAP, UDDI) pour la réalsaton des servces Web smple ans que des standards plus complqués comme les langages de spécfcaton de procédés méters(ex. WS- BPEL [OASIS2005]) qu spécfent la composton des servces smples. Ben que la technologe de servces Web ne sot pas la seule manère de réalser un procédé nter-organsatonnel, elle est la technologe essentelle consdérée par l ndustre. Avec les servces Web, un déf fondamental pour l nformatque réparte est : comment fournr une manère unforme de décrre des composants ou des servces dans un réseau, de les localser, et de leur accéder. Ce problème est abordé en utlsant les concepts et les technologes qu sont développés d une voe ouverte, utlsant des assocatons d ndustre et de larges consortums tels que W3C et l organsaton pour l avancement des normes structurées de l nformaton (OASIS). Ans, l utlsaton des technologes Web ans que les concepts assocés sont ncontournable pour la réalsaton des procédés méters effcaces. Dans un premer temps, nous utlsons les servces Web comme le support de réalsaton de nos contrbutons conceptuelles. Par la sute, nous étudons les apports secondares des efforts de standardsaton comme la moblté des spécfcatons entre dfférents outls et organsatons. Notre approche est basée sur ce deuxème aspect. Celle-c est explquée dans la secton dées centrales de la thèse (vor la secton 2.4.1). Workflow Le chox des modèles de concepton pour les procédés méters ou ben pour des systèmes d nformaton en général semble fare parte des sujets à polémques, tant l est ntmement lé à la culture scentfque des ndvdus, au domane d applcaton et auss à la destnaton des aspects qu on peut en dérver. L dée de modélsaton des procédés n est pas nouvelle, on la trouve dans la descrpton de procédés de fabrcaton de logcel dès 1987[Osterwel1987], semblable aux langages de programmaton, mas adaptés aux besons spécfques du domane pour décrre ces procédés. S l émergence de l approche workflow dans les systèmes d nformaton quotdens est nouvelle, l dée d utlser des approches smlares est ben plus ancenne. L ntatve Worflow Management Coalton[WfMC1996] qu regroupe alors un ensemble d ndustrels et de chercheurs académques, a proposé des standards pour le workflow sute aux ndénables besons du marché et au manque de standardsaton. Les efforts ndvduels comme ceux de Van Der Aalst et son groupe ont donné leu à pluseurs résultats ben établs facltant la compréhenson et la mse en œuvre comme les patrons de workflow[van der Aalst et al.2000]. A ben des égards, les technologes des servces Web et leur propres efforts de standardsaton s ntéressent à la modélsaton des procédés nter-organsatonnels orentés servces d un pont de vue worfklow. Cec est tout à fat lé aux connassances communes étables dans le cadre des efforts de standardsaton du workflow. WS-BPEL[OASIS2005] qu est le langage de-facto de spécfcaton des procédés méters sut les mêmes voes que celles qu ont fat le workflow l une des approches essentelles pour la modélsaton des procédés méters. Dans cette thèse, nous pensons que plutôt que de défnr de nouveaux langages de spécfcaton de procédés, l est plus effcace de réutlser des formalsmes exstants structurés autour de l approche workflow, de les adapter et de les nterfacer. 9

26 Chaptre 2. Problématque générale et objectfs de la thèse Systèmes décentralsés et égal-à-égal (P2P) La vson classque d un système de geston de procédés méters est centralsée. En conséquence, elle est caractérsée par les lmtatons nhérentes des systèmes centralsés tant matérellement que conceptuellement. Depus 1999, date à laquelle l applcaton Napster connut un succès, le modèle égal-à-égal attre l attenton des acteurs de la communauté de l ngénere des procédés méters. Les scentfques et les ndustrels voent en cette approche une vértable alternatve aux approches centralsées qu sont les modèles actuellement utlsés au sen des organsatons. L établssement des nteractons égal-à-égal entre les partcpants d un procédé méter présente de nombreux avantages qu repoussent les lmtes ndutes par le modèle centralsé. S les premères applcatons qu mplémentent l approche égal-à-égal état des applcatons de dstrbuton de fchers multmédas soums à des drots d auteurs, actuellement l ensemble des systèmes de geston de procédés méters sont repensables et repensés pour être déployés selon la même approche. La décentralsaton de l exécuton des procédés méters est dentfé comme une pste de recherche prometteuse depus une dzane d année. Ans, l utlsaton des paradgmes de la décentralsaton des procédés méters précède l apparton des systèmes égal-à-égal[alonso et al.1997], mas avec cepant des lacunes qu rédusent séreusement leur champ d applcaton. Dernèrement, les archtectures orentés servces ntrodusent de nouvelles caractérstques qu ne sont pas en adéquaton avec les ancennes technologes des workflows décentralsés comme par exemple OSIRIS[Schuler et al.2004], SELF- SERV[Benatallah et al.2002] ou PPWD[Fakas and Karakostas2004]. Même s l exécuton décentralsée des procédés méters mplémentés par les workflows a été dentfée comme une pste ntéressante avant une dzane d année, la plupart des contrbutons précédent les archtectures orentées servces et les efforts de standardsaton des procédés méters. Les contrbutons qu suvent les efforts de standardsaton et portant sur le workflows décentralsés suvent les mêmes approches que celles développées dans les travaux antéreurs. Pluseurs travaux récents ont dentfés des approches alternatves à la concepton et l mplémentaton des procédés méters nter-organsatonnels [Kng1983] [Schuler et al.2004] [Weerawarana et al.2005] [Fscher2007] pour dépasser les nombreuses lmtatons des systèmes centralsés. L exécuton décentralsée est une de ces approches alternatves. Il est à noter que notre compréhenson de décentralsaton est lon des applcatons de partage de fcher multméda. Nous dscutons les paradgmes lées à la décentralsaton et d égal-à-égal dans le contexte de l ngénere de procédés méters. La contrbuton de cette thèse portera sur les aspects de décentralsaton des procédés méters nter-organsatonnels orentés servces. 2.3 Problématque Dans cette secton, nous nous penchons sur la problématque précse de cette thèse. La problématque générale porte sur la proposton d un envronnement décentralsé pour la concepton et l exécuton des procédés méters nter-organsatonnels orentés servces. Notre compréhenson de la décentralsaton se réfère aux exécutons où les servces peuvent établr des nteractons d égal-à-égal. Cette proposton est motvée par les lmtatons des envronnements exstants face aux exgences des systèmes qu nous ntéressent. Dans un contexte nter-organsatonnel qu ntègre des organsatons autonomes ntegrés, l est souvent souhatable d établr des relatons égal-à-égal entre elles. Ben que consdéré aujourd hu comme étant un des outls les plus pussants pour supporter l automatsaton des procédés méters, l approche workflow souffre des lmtes conceptuelles, et matérelles de la centralsaton. Pour explquer nos motvatons, nous utlsons l exemple smple suvant. 10

27 2.3. Problématque Lvrason Inspecteur Polce a 1 :H d 1 d 3 d 4 a 5 :L a 2 :L a 4 :Ins Assurance a 3 :P a 6 :B d 2 Banque Hôptal Fg. 2.1 Un exemple de motvaton Un exemple de motvaton smple La fgure 2.1 présente un procédé nter-organsatonnel dans sa généralté. Il s agt d un procédé exécuté par une organsaton d assurance en vue de détermner s la réclamaton de snstre d un souscrpteur est remboursable. Ce scénaro peut être résumé comme sut. En cas de snstre, le souscrpteur appelle la polce et les servces d urgence qu vont l ader pour l ncdent. La polce et les servces d urgence gérés par l hôptal local préparent respectvement deux rapports décrvant l ncdent et l état du souscrpteur. Par la sute, le souscrpteur dot déposer sa réclamaton de remboursement dans un déla détermné au sège de l organsaton d assurance. Quand la réclamaton est reçue, le procédé llustré dans la fgure 2.1 est lancé par l organsaton d assurance. Dans un premer temps, l organsaton d assurance contacte la polce et l hôptal pour récupérer les rapports respectfs qu ont été préparés au moment de l ncdent. Ces rapports sont mportants pour détermner la valdté de la demande de remboursement. La réclamaton et les rapports du snstre sont examnés par un nspecteur qu s engage à les trater le plus rapdement et le plus objectvement possble. S la réponse de l nspecteur est affrmatve, la réclamaton est remboursée. L ndemnsaton est réalsée va la banque avec laquelle l organsaton d assurance travalle. Le rapport de l nspecteur et les détals de l ndemnsaton sont transms au souscrpteur par un servce de lvrason. Ce procédé nter-organsatonnel est modélsé comme un workflow et exécuté par l organsaton d assurance. Les autres organsatons sont accessbles par les servces Web. Ces servces Web sont appelés : Hôptal, Polce, Inspecteur, Banque, Lvrason. On peut également ajouter Assurance comme un servce comme les autres. Le workflow de la fgure 2.1 llustre les dépances de contrôle et de données des actvtés du procédé. Les 11

28 Chaptre 2. Problématque générale et objectfs de la thèse dépances de contrôle caractérsent l ordre partel de l exécuton des actvtés alors que les dépances de données caractérsent les relatons de type entrées/sortes des actvtés. Dans l llustraton, chaque actvté décrt son dentté et le servce évoqué pour son exécuton. Dans une approche workflow classque, l organsaton d assurance évoque les servces appartenant aux organsatons en suvant la spécfcaton du modèle de workflow. Cela veut dre que les organsatons mplquées sont coordonnées par l organsaton d assurance et qu elles sont solées des unes des autres. Par exemple, les sortes des servces Polce et Hôptal sont utlsées comme entrées du servce Inspecteur. Par contre ces données ne sont pas transmses de servce producteur au servce consommateur. Étant le coordnateur du procédé, Assurance fat l opératon de routage. Comme les données ne sont pas drectement échangées entre les servces concernés, la quantté globale d nformaton augmente et surcharge l nfrastructure. Cela est une lmtaton ben connue entre autres des systèmes centralsés (vor le chaptre État de l art). Comme nous l avons soulgné dans les sectons précédentes, les nteractons d égal-à-égal entre les organsatons sont souhatables pour pluseurs rasons, mas la vson classque de l approche worfklow ne permet pas de telles nteractons. Pour montrer l ntérêt d avor des nteractons d égal-à-égal, nous ajoutons les restrctons suvantes au scénaro. 1. Hôptal peut fournr le rapport de l accdent seulement au souscrpteur et à la Polce, 2. Inspecteur peut recevor les rapports seulement de Polce et/ou Hôptal, 3. Banque peut être évoquée seulement par Assurance La présence de ce type de restrcton semblent très rasonnable dans le contexte où pluseurs servces mutuellement non-confants dovent être combnés. Par exemple, le rapport fourn par Hôptal peut contenr des nformatons confdentelles qu un ters ne dot pas obtenr. Pourtant, comme Polce est un servce appartenant au gouvernement, l peut être consdéré comme fable. Une stuaton smlare est valable pour Inspecteur car, les rapports de Polce et Hôptal contennent des nformatons sensbles qu peuvent être modfées par des organsaton d assurance pour empêcher les remboursements. En conséquence, Inspecteur peut voulor recevor les rapports drectement de la part des servces qu les fournssent. Dans ce contexte, la présence de la premère et de la deuxème restrcton empêchent l exécuton du procédé par un système de geston de workflow classque. Parce que quand le workflow évoque Polce, l reçot le rapport qu l dot router à Inspecteur. Pourtant la restrcton de ce derner empêche cet opératon (la restrcton 2 c-dessus). De même, Hôptal ne peut pas être évoqué par Assurance pour la récupératon du rapport. Il est à noter que l on peut enrchr la sémantque de ces types de restrctons en ajoutant des proprétés temporelles, spatales ou condtonnelles smlares selon les restrctons smlares des systèmes de geston de workflow [Bertno et al.1999] [Josh et al.2005] [Daman et al.2007] [Bertno2004]. Auss, Il est clar que les envronnements classques de composton de servces ou de geston des procédés méters actuels n ont pas les bonnes fonctonnaltés exgées par la décentralsaton du contrôle. Une premère queston qu vent alors est : Comment les servces composés peuvent connaître et établr des nteractons avec les autres servces du même procédé nter-organsatonnel? Comment peuvent-ls savor à quel servce envoyer leur sortes ou ben de quel servce recevor de données? Dans une composton centralsée comme présentée dans l llustraton, les servces sont mutuellement solés et répondent aux nvocatons venant d un servce clent qu joue le rôle de coordnateur. Le coordnateur fat appel aux opératons de servce déclarées dans son nterface. Il est à noter que l nterface d un servce est statque et ne peut pas être modfée dynamquement même s l organsaton qu mplante le servce peut modfer son fonctonnement nterne. Les nteractons que nous consdérons ont pour but d échanger le contrôle et les données et ne sont 12

29 2.4. Objectfs de la thèse pas l mplantaton des restrctons spécales telles que les poltques déclarés par les servces. En partant de cette queston, on peut poser une deuxème queston smlare. Comment les servces composés peuvent se comporter dfféremment pour chaque procédé dont ls font parte en foncton de crtères dfférentes? Dans cet exemple, les restrctons qu dovent être respectés ne sont valable que pour ce scénaro. Mas, étant donné qu un servce est une entté autonome, un autre clent peut voulor l utlser en mposant d autres types de restrctons. Là encore, les mplantatons actuelles des servces ne supportent pas ce type d exécuton où les servces peuvent se comporter dfféremment en foncton des composton. Parlant des restrctons qu dovent être respectées, on peut poser la queston suvante. Comment peut-on spécfer les restrctons qu concernent les nteractons d égal-à-égal dans un procédé nter-organsatonnel? Qu les défnt? Est-ce qu l y a des restrctons par défaut? Les besons exprmés pour l exécuton des procédés méters nter-organsatonnels sont souvent proches de ceux exprmés dans des domanes varés comme la geston décentralsée de base de données [Josh et al.2005] [Bertno2004] ou la séparaton des préoccupatons dans les systèmes de geston de workflow [Atlur and Warner2005] [Atlur et al.2001] qu ne sont pas adaptés à l expresson des relatons d égal-à-égal entre les servces. Dans l exemple de l llustraton de la fgure 2.1, les nteractons Hôptal/Polce et Polce/Inspecteur sont mutuellement en adéquaton. En conséquence, Polce peut évoquer Hôptal et recevor les sortes de ce servce. Par la sute, Polce peut évoquer Inspecteur avec les sortes de Hôptal. Ans, un procédé nter-organsatonnel qu n est pas exécutable avec une approche centralsée, peut être fasable en révsant les nteractons des servces composés. Pourtant, cette approche nécesste la consdératon de restrctons dverses qu n exste pas dans les exécutons conventonnelles. Par exemple, est-ce que Polce a le drot de fournr les sortes de Hôptal à un autre servce à qu Hôptal ne fournt pas ses sortes? Comment exprmer des restrctons smlares? Quelles est la nature de ces spécfcatons? En partant de ces observatons, le but de notre contrbuton est de fournr des réponses compréhensbles et rasonnables aux queston suvantes : 1. Comment les servces peuvent établr des nteractons d égal-à-égal d une manère systématque quand ls sont composés au sen d un procédé nter-organsatonnel? 2. Comment les restrctons concernant les nteractons d égal-à-égal peuvent être spécfées et tratées? 3. Comment peut-on mplémenter des servces qu peuvent supporter des nteractons d égalà-égal tout en respectant leur autonome et en respectant les efforts de standardzaton? 2.4 Objectfs de la thèse Dans cette secton, nous présentons les objectfs de cette thèse et nous résumons nos contrbutons. L objectf général de cette thèse est de fournr un envronnement d exécuton décentralsée pour les procédés méters nter-organsatonnels orentés servces. Nous nous ntéressons aux aspects conceptuels de la décentralsaton ans qu aux défs archtecturaux pour son mplémentaton. Nous avons mentonné dans les sectons précédentes la dversté des crtères qu dovent être consdérés. Dans un premer temps, notre objectf est de trater les crtères les plus essentels et de donner un aperçu sur la satsfacton d autre types de crtères selon l approche proposée Idées centrales de la thèse La rason prncpale pour laquelle une exécuton décentralsée n est pas toujours fasable est que les servces composés ne se comportent pas comme exgés par la décentralsaton. En effet, 13

30 Chaptre 2. Problématque générale et objectfs de la thèse Servce Web Servce Web L nterface du servce Web (a) (b) Fg. 2.2 La fgure(a) s agt de l utlsaton d un servce classque, l opératon du servce est évoquée par un message du clent. La fgure(b) llustre un servce qu mplémente notre approche, l est évoqué par un procédé qu sera exécuté par le servce un servce établt des nteractons comme son nterface le décrt, pourtant les exgences en termes d nteractons peuvent varer d un procédé nter-organsatonnel à un autre. Une pratque qu nous a semblée ntutve pour résoudre ce problème est d adapter le comportement d un servce en foncton des crtères de décentralsaton au moment où l est chos pour fare parte d un procédé nter-organsatonnel. Pour ce fare, un servce peut recevor un procédé méter quand l est chos pour un procédé nter-organsatonnel et exécuter ce procédé reçu pour établr les nteractons approprées avec d autres servces qu exécutent leur propre procédé reçu. Il est à noter que les procédés ncluent les actvtés approprées pour l établssement des nteractons exgées[yldz and Godart2007f]. Ce mode de traval est llustré dans la fgure 2.2. Avec cette approche, la composton llustrée dans la fgure 2.1 est exécutée comme décrte dans la fgure2.3. Dans cette dernère, Assurance défnt un procédé centralsé qu compose les servces utlsés. Par la sute, l utlse ce procédé pour en dérver des fragments qu seront exécutés par les servces composés. Les fragments de procédé sont déployés vers les servces composés par le servce Assurance. Cela leur permet d établr des nteractons égal-à-égal en les exécutant. La geston décentralsée des procédés méters nter-organsatonnels où les partcpants peuvent avor des nteractons confgurables n est pas une dée nouvelle. Pour ce fare, les propostons exstantes ntègrent pluseurs nveaux de couches logcelles dont les partcpants dovent dsposer. Le but de ces derners est supporter des protocoles de coordnaton sophstqués entre les partcpants. Par nature, ces couches d applcatons sont souvent tellement complexes que assumer leur exstence dans le contexte du Web est utopque. Sans aller plus lon dans les lmtatons des approches exstantes qu sont largement approfondes dans la sute, nous pouvons dre que la façon de vor une exécuton décentralsée avec les procédés méters déployés au près des servces composés est tout à fat nouvelle. La motvaton globale de cette approche qu nous servra de fl drecteur tout au long de cette thèse découle de ces dfférents efforts de standardsaton. Les efforts de standardsaton des servces Web sont fondés sur XML (extensble Markup Language). XML est un standard de représentaton de données sem-structurées. Dans une descrpton XML, la structure de données est fourne par le bas de l utlsaton de balses. La représentaton des documents XML n est pas auss rgde que celle d une base de données relatonnelle par exemple. En se basant sur XML, les standards des technologes servces Web 14

31 2.4. Objectfs de la thèse Lvrason Inspecteur Polce Assurance Déploement des fragments par Assurance Interacton des fragments Banque Hôptal Fg. 2.3 L applcaton de l approche au procédé de l exemple de motvaton fournssent une base solde pour le développement des procédés méters nter-organsatonnels. De plus, les spécfcatons codées en ces standards peuvent être échangées entre dfférentes plateformes et même dfférentes organsatons. Par exemple, un procédé nter-organsatonnel codé dans un langage standard comme WS-BPEL, peut être transms d une organsaton vers une autre. Comme l s agt d une spécfcaton standard, l organsaton qu reçot le procédé peut l exécuter faclement sans avor un nveau de logcel addtonnel à part un moteur d exécuton WS-BPEL. Cec est valable pour les procédés WS-BPEL nstancés. La caractérstque de cette approche est llustrée dans la fgure 2.2. Cette façon de vor les choses est totalement nouvelle comparée aux envronnements de composton de servces classque. La plupart des outls de composton ne sont que des applcatons qu cherchent la cohérence syntaxtque entre les nterfaces des servces mas ne fournssent qu une ade très relatve à la spécfcaton et à la satsfacton du comportement attu du servce dans le procédé nter-organsatonnel. De la même façon, les servces ne cherchent pas à s mplquer dans un procédé d une manère collaboratve en nteragssant avec les autres servces. Ils ont une approche passve d où ls répondent aux appels reçus. Conformément à ce qu a été requs, cette approche ne nécesste pas la présence de nveaux logcels sophstqués que les servces dovent mplémenter, parce qu un moteur d exécuton de procédé standardsé qu exste derrère les nterfaces des servces peut être faclement fourn par les organsatons. Les questons essentelles de cette approche sont comment fournr les procédés qu dovent être exécutés par les servces (organsatons) composés dans le cadre du procédé nter-organsatonnel? Quelles sont les restrctons à respecter? Comment un procédé peut être déployé vers un servce? Cela est d autant plus vra qu l n exste pas actuellement de 15

32 Chaptre 2. Problématque générale et objectfs de la thèse consensus sur la façon de développer un procédé méter d une manère automatque en utlsant des servces exstants. Il sufft pour s en convancre de constater la multtude des propostons exstantes. Dans la secton suvante, nous dscutons les étapes essentelles de notre démarche pour donner un aperçu compréhensble de notre contrbuton Les grandes lgnes de la démarche Dans cette secton, nous présentons les grandes lgnes de notre démarche. Comme soulgné dans les sectons précédentes, notre objectf est de fournr un envronnement d exécuton décentralsée pour les procédés méters nter-organsatonnels. Pour ce fare, nous utlsons des procédés dynamquement déployés au près des servces composés. La concepton des technques mplque le chox d un ensemble de formalsmes adaptés à la fos à leur expresson et à la maîtrse de leur élaboraton. Notre approche nécesste une descrpton du procédé nter-organsatonnel qu compose les servces d une manère centralsée. Cette descrpton centralsée peut être fourne en utlsant dfférentes technques de composton automatque [Berard et al.2005] [Bultan et al.2006] [Pstore et al.2005]. Nous supposons que cette descrpton est fate dans une étape antéreure qu ne nous concerne pas dans cette thèse. Smlare à une descrpton d un workflow, cette descrpton exprme le flux de contrôle des nvocatons des opératons appartenant aux servces composés. Dans un premer temps, l est nécessare de fournr une technque qu fournt les procédés coopérants qu correspondent à la descrpton centralsée tout en gardant la même sémantque. Cette technque dot démontrer comment un procédé nter-organsatonnel peut être décentralsé sans consdérer des restrctons spécales comme les poltques du flux d nformaton de notre exemple de motvaton. Cette étape nécesste une consdératon formelle de la descrpton centralsée. Parce que la préservaton de la sémantque dans une exécuton décentralsée n est pas une tâche trvale et nécesste de lever les ambguïtés. De la même façon, une deuxème consdératon formelle dot porter sur les restrctons qu spécfent les nteractons exgées des servce composés. Ces restrctons peuvent être des restrctons par défaut qu dovent être consdérées pour n mporte quelle opératon de décentralsaton qu fournt des procédés coopérants ou ben des restrctons qu caractérsent les exgences spécales des acteurs prncpaux comme les servces et les concepteurs. La défnton des restrctons qu gouvernent l opératon de décentralsaton dot être flexble pour permettre leur extensblté vers des restrctons dverses qu ne seront pas détallées dans cette thèse. Soulgnons auss que les procédés décentralsés, les restrctons ans que le opératons qu les tratent, dovent être décrts d une manère générque ndépamment des langages de spécfcaton. Conformément à ce qu a été présenté dans la fgure 2.2, le transfert d un procédé d un clent vers un servce nécesste une archtecture de servce spécale. Même s cette dernère n est pas une archtecture qu nécesste des protocoles auss sophstqués que ceux des travaux lés, elle nécesste néanmons d être approfonde pour valder le concept Contrbutons de la thèse 16 Cette secton résume les contrbutons de cette thèse. 1. Nous ntrodusons une méthodologe et des outls pour décentralser un procédé nterorgansatonnel centralsé en respectant la sémantque de ce derner et en allant vers des nteractons d égal-à-égal entre les servces composés. Dans un premer temps, nous ntrodusons une technque qu formalse cette opératon sans se baser sur des crtères précs. Il s agt des structures de données et des algorthmes qu respectvement caractérsent et

33 2.5. Synthèse tratent les procédés méters en vue de fournr les procédés coopérants que les servces composés dovent mettre en œuvre. 2. Ensute, nous ntrodusons un langage de base pour exprmer les restrctons mposées aux nteractons d égal-à-égal des servces composés. Ce langage est basé sur la modélsaton de la séparaton des devors dans les systèmes de geston de workflow. Nous présentons également les algorthmes qu tratent ce langage en vue de spécfer les nteractons des servces. Par la sute, les technques développées dans la premère contrbuton sont adaptées à cette deuxème contrbuton qu s agt de confgurer en permettant la confguraton des nteractons des procédés coopérants fourns. 3. La trosème contrbuton de cette thèse se penche sur la sélecton dynamque des servces pant l exécuton décentralsée d un procédé nter-organsatonnel avec les procédés coopérants. Dans un premer temps, l s agt d dentfer les stuatons problématques que peuvent exster entre les procédés coopérants déployés dynamquement. Nous proposons ensute une technque pour empêcher de telles stuatons. 4. La dernère contrbuton de cette thèse concerne la valdaton des propostons conceptuelles c-dessus. Outre la producton des procédés coopérants en utlsant la spécfcaton WS-BPEL, nous présentons une archtecture de référence pour les servces qu peuvent supporter ce mode de traval. Nous présentons également les résultats de nos expérmentatons. Il est à noter que les contrbutons conceptuelles nécesstent une base formelle solde pour fournr les preuves formelles concernant l équvalence de l exécuton centralsée et l exécuton décentralsée ans que la complétude des restrctons et la complexté de leur tratement. Nous avons également complété nos contrbutons par des analyses formelles. 2.5 Synthèse La dffculté de mse en œuvre des systèmes de geston de procédés méters tent aux problèmes de spécfcaton, d organsaton, de développement, d ntégraton et de vérfcaton d ensemble de facteurs nombreux et complqués. Dans un contexte nter-organsatonnel, ces problèmes sont aggravés pour les servces réparts par la dffculté de maîtrser dynamquement leur autonome et la multtude de leur nteractons. Même s les technologes de servces Web adent à maîtrser les problèmes sous-jacents de communcaton, l analyse et la confguraton des nteractons sont d autant plus dffcles à contrôler que les exgences des servces et des concepteurs peuvent être varées, contradctores, et qu un fonctonnement répart empêche toute vson globale. Les systèmes de geston décentralsés du workflow ntrodusent des avantages ntéressants pour maîtrser les dffcultés actuelles des procédés méters nter-organsatonnels orentés servces. Une telle exécuton décentralsée peut correspondre aux réels besons des procédés nterorgansatonnels s elle combne les avantages respectfs des ntatves complémentares. Les efforts de standardsaton des servces Web facltent la réalsaton des exécutons décentralsées. Cette thèse s nscrt dans ce contexte. Nous ntrodusons une nouvelle approche pour l exécuton décentralsée des procédés nter-organsatonnels orentés servces. Cette approche est motvée par les efforts de standardsatons et leur apports secondares. Il s agt de prre une descrpton centralsée d un procédé nter-organsatonnel et de dérver des procédés coopérants qu mplémentent les sémantque de ce derner avec des nteractons d égal-à-égal entre les servces composés. Apparemment smple, cette approche cache un grand nombre de concepts et de 17

34 Chaptre 2. Problématque générale et objectfs de la thèse sous-entus. Elle suppose tout d abord que les servces composés peuvent recevor des procédés qu seront déployés par leur clent et les exécuter. Les servces développés à l heure actuelle ne fonctonnent pas de cette manère. En conséquence, notre approche nécesste des consdératons archtecturales même s ces dernères sont relatvement smples à réalser. Il est tout à fat naturel que la concepton des exécutons décentralsées mplque le chox d un ensemble de crtères adaptés aux domanes d applcaton vsés par la décentralsaton. Pour ce fare, nous ntrodusons un langage smple mas flexble et extensble pour caractérser les crtères qu peuvent exster dans un contexte nter-organsatonnel. Ces crtères portent sur des aspects qu concernent, entre autres, la sécurté, l ntmté et la fablté des servces ans que le pont de vue des concepteurs. Pour ce fare, le procédé nter-organsatonnel ans que les crtères mposés à la décentralsaton dovent être ben comprs par ceux qu devront fournr une exécuton décentralsée équvalente. Auss, notre approche décompose le problème en sous-problèmes plus facles à appréher. 18

35 Chaptre 3 Etat de l art Sommare 3.1 Introducton L approche orentée servce et ses technologes : Le dogme Pourquo et comment employer l approche orentée servce? Technologes relatves basées sur XML La composton des servces Synthèse sur l approche orentée servce Systèmes d nformaton décentralsés et par-à-par Pourquo avor des systèmes décentralsés? Quels sont les défs et les lmtatons des systèmes décentralsés? Synthèse sur les systèmes décentralsés par-à-par Worflow La modélsaton des procédés méters L ntatve Workflow Worklow centralsé versus décentralsé Autres travaux lées Synthèse sur le workflow décentralsé Synthèse et stuaton par rapport à d autres approches de la problématque Introducton Il exste à l heure actuelle peu de propostons qu permettent de comprre et de maîtrser l exécuton décentralsée d un procédé qu compose un ensemble de servces. Les rasons de la dffculté de compréhenson sont multples. Une dffculté essentelle tent aux problèmes de spécfcaton d un procédé nter-organsatonnel comme une composton de servces. Les problèmes sous-jacents de communcaton au nveau de l ntégraton des servces composés sont d autant plus dffcles à comprre que les paradgmes de modélsaton sont abstrats. Parce que la concepton et l mplémentaton mplquent le chox d un ensemble de technologes adapté à la fos à l expresson des procédés et à leur exécuton sur un réseau de communcaton. La compréhenson se complque consdérablement s on pense aux motvatons des exécutons décentralsées. 19

36 Chaptre 3. Etat de l art Dans ce chaptre, nous fasons le parcours de la lttérature relatve à notre traval dans l objectf de présenter un état de l art. Dans la premère parte de ce chaptre, nous présentons l approche orentée servce et ses technologes qu consttuent le nveau d mplémentaton de notre approche. Il est à noter qu une dée clé de notre approche est l utlsaton des standards ntroduts pour l approche orentée servce. Le rôle de la premère secton, en permettant une ntroducton progressve des concepts par rapport aux défntons habtuelles dans le domane, est essentellement pédagogque. Nous cherchons à explquer l apport des efforts de standardsaton à l exécuton décentralsée d un procédé. La deuxème parte de ce chaptre porte sur la présentaton des systèmes d nformaton décentralsés et par-à-par. Dans un premer temps, nous présentons un ensemble de caractérstques qu spécfent des systèmes décentralsés. Nous cherchons à en soulgner les avantages dans un contexte auss ben organsatonnel qu opératonnel. Ensute, nous dscutons judceusement les contrantes, les défs et les lmtatons de la décentralsaton. La trosème parte est consacrée à la présentaton des travaux qu portent sur la modélsaton des procédés par le bas de l ntatve workflow. Cette parte s appue, d un côté sur la modélsaton des procédés par des worflows, d un autre côté sur l étude des dfférents modaltés d exécuton d un worflow. Nous décrvons enfn les travaux smlares à nos contrbutons. Par une analyse crtque, nous montrons les ntérêts et les lmtes respectfs ans que les aspects complémentares des dfférents travaux lés. Compte tenu du fosonnement actuel du domane, l est névtable que l état de l art ne trate pas de manère exhaustve l ensemble des travaux réalsés. Néanmons, nous croyons que l analyse fate dans ce chaptre couvre rasonnablement ben les prncpaux travaux pertnents, que ce sot en matère de systèmes d nformaton décentralsés et égal-à-égal (P2P pour peer-to-peer en anglas), de modèles de workflows, ou d approche orentée servce. 3.2 L approche orentée servce et ses technologes : Le dogme Les systèmes d nformaton sont basés aujourd hu de plus en plus sur des technologes standardsées de l Internet. Les efforts de standardsaton dans ce contexte ont perms l émergence des servces Web [Alonso et al.2004] comme support concret de développement des applcatons accessbles par Internet. Ans, les technologes assocées aux servces Web sont devenues ncontournables pour le développement des applcatons nteragssant les unes avec les autres par le bas de l Internet [Weerawarana et al.2005]. La noton de servce désgne une applcaton logcelle mse à dsposton sur l Internet par un fournsseur, et accessble par des clents à travers des protocoles standards [Curbera et al.2002]. Le servce défnt une abstracton. Il procure une applcaton logcelle à des clents. Il possède une référence unque qu l dentfe sur l Internet. Un servce est encapsulé. Les clents ne peuvent accéder, utlser, modfer un servce que par l appel aux opératons mses à leur dsposton par le servce lu-même. Chaque servce est ans proprétare et responsable de ses données et ses opératons. Hstorquement, la noton d objet, qu est apparue l y a une qunzane d années, donnat le premer élément de réponse à la problématque mas la noton de servce l a porté à un nouveau nveau [Aoyama et al.2002]. La programmaton par objets a apporté un ensemble de prncpes de concepton dont la noton de servce a hérté. Pourtant, l y a des dfférences mportantes entre la programmaton par objets et l approche servce. Par exemple, les objets sont dépants des langages et d un envronnement d exécuton. Les objets sont crées et détruts localement après leur utlsaton alors que les servces ne les sont pas. Les objets sont locaux au système qu les gère alors que les servces sont accessbles sur un réseau. En conséquence la 20

37 3.2. L approche orentée servce et ses technologes : Le dogme geston des exceptons est plus sophstquée [Curbera et al.2003]. On peut multpler les exemples qu séparent le paradgme servce et le paradgme de la programmaton par objet Pourquo et comment employer l approche orentée servce? L approche orentée servces est un nouveau style de concepton et d mplantaton permettant aux entreprses de créer rapdement de nouvelles applcatons dstrbuées. Pluseurs défntons des servces et en partculer des servces Web sont mses en avant par pluseurs auteurs. Pour donner une défnton précse, nous consdérons la défnton proposée par le consortum W3C : A Web servce s a software system desgned to support machne-to-machne nteracton over a network. t has an nterface descrbed n a machne-processable format (specfcally WSDL). Other systems nteract wth the Web servce n a manner prescrbed by ts descrpton usng SOAP [Box et al.2000] messages, typcally conveyed usng HTTP wth an XML seralzaton n conjunton wth other Web-related standards. L objectf vsé avec le développement des technologes des servces Web est une melleure consdératon de l nteropérablté des applcatons tournant sur des plate-formes hétérogènes. Par rapport à d autres plates-formes pour le développement d applcatons dstrbuées telles que CORBA [cor] et Java RMI[jav], l une des dfférences prmordales est que les servces Web n mposent pas de modèles de programmaton spécfques. En d autres termes, les servces Web ne sont pas concernés par la façon dont les messages sont produts ou consommés par des applcatons orentées servces Web. Cec permet aux veurs d outls de développement d offrr dfférentes méthodes et nterfaces de programmaton au-dessus de n mporte quel langage de programmaton, sans être contrants par des standards comme c est le cas de CORBA qu défnt des ponts spécfques entre le langage de défnton IDL et dfférents langages de programmaton. Ans, les fournsseurs d outls de développement peuvent faclement dfférencer leurs produts avec ceux de leurs compétteurs en offrant dfférents nveaux de sophstcaton. Par exemple, l est possble d offrr des envronnements pour des méthodes de programmaton de servces Web mnmalstes au-dessus de plates-formes relatvement légères comme c est le cas de NuSOAP pour le langage PHP ou d Axs. En revanche, des plates-formes plus lourdes telles que BEA WebLogc, IBM Websphere ou.net offrent un envronnement pour des méthodes de développement très sophstquées [Dumas and Fauvet2006]. Ben qu elle faclte le développement des applcatons répartes, l aspect technque n est pas la seule rason qu explque l adopton rapde des technologes des servces Web. Nous allons détaller ces caractérstques dans les sectons suvantes. La plupart des entreprses produsent et vent leur produts à leur clents afn de réalser les objectfs du méter tels que les objectfs fnancers. Leur procédés méters spécfent comment les produts sont conçus, produts, ms sur le marché, dstrbués et vus. D un pont de vue abstrat, le procédé méter d une organsaton est une projecton des produts qu elle offre. Donc, la vtesse du changement de l nfrastructure ou de la créaton de nouveaux procédés méters correspondent à la vtesse du changement ou créaton des produts. Afn de survvre dans un marché hautement dynamque et ouvert aux changements régulers, les entreprses dovent être flexbles. Ic, la flexblté veut dre la capacté de réagr rapdement, de préférence plus vte que la compéttvté, aux exgences des clents, nouveaux produts offerts par les compétteurs exstants et de nouveaux et aux avancement de technologes. En conséquence la flexblté d une entreprse est la projecton de sa capacté d adaptaton de son procédé méter. Les consttuants de la défnton d un procédé méter peuvent être traduts drectement en actons qu sont nécessares pour changer le procédé : changer le flux des actvtés du procédé, changer les acteurs qu exécutent les actvtés ; changer les outls qu supportent ces actvtés, ans de sute. Cela peut 21

38 Chaptre 3. Etat de l art auss fournr un contexte où l exécuton des actvtés du procédé dot être déplacé vers les partenares. Dans ce contexte, un certan nombre d aspect organsatonnels explquent l acceptaton rapde des technologes servces Web. Le beson d un couplage fable La possblté d établr des communcatons avec les servces, qu sont découverts dynamquement, exge un couplage fable entre le clent et le fournsseur du servce à évoquer. La noton de couplage fable est une des caractérstques essentelles des technologes des servces Web. Cette noton exclut toutes les hypothèses à propos des plate-formes spécfques que le clent ou le fournsseur mpose. Cec est valable pour le format et le protocole qu caractérsent l nteracton de ces derners. Ces caractérstques sont à base de l adaptaton des servces Web pour leur utlsaton au sen des procédés méters. Le beson d ntéropérablté Aujourd hu, dfférentes technologes pour réalser des applcatons dstrbuées exstent telles que Common Object Request Broker Archtecture (CORBA) [cor], Java 2 Platform, Enterprse Edton (J2EE) [Haugland et al.], et Component Object Model (COM)[com1993], chacune en se basant sur dfférent concepts et modèles d objet. En conséquence, l ntéropérablté entre ces plate-formes est dffcle. Dans un premer temps, la dffculté tent aux formats de messages échangés et aux protocoles de communcaton employées. Par la sute vennent des problèmes d ntéropérablté de haut-nveaux tels que le support transactonnel, la sécurté et l ntmté. Par exemple, une smple tâche qu est exécutée sur pluseurs plate-formes avec des supports transactonnels dfférent ne peut pas mettre en œuvre une caractérstque transactonnelle cohérente. Les servces Web fournssent un ensemble de technologes (WS-*) adaptées à l expresson des exgences dans un contexte de programmaton réparte. Le beson pour la composton de servces S on compare aux technologes exstantes telles que les technologes clent/serveur, les applcatons Web et de nombreuses autres que nous avons mentonnées dans les sectons précédentes (.e. CORBA, COM), les servces Web permettent les échanges entre entreprses, ndépamment d un langage de programmaton donné, selon une orentaton messages tout en supportant dfférent modes de transport de ces derner. Par rapport aux autres applcatons Web, les servces Web fonctonnent sur des nteractons applcatons-applcatons. Cela permet de les ntégrer dynamquement par composant, et naturellement, offre la possblté d agréger des servces. Cette nouvelle tance pour gérer ces procédés nter-organsatonnels consste à composer les servces. L mpact sur les procédés méters est double, car d une part les procédés orentés servce sont exposés comme des servces, et d autre part, ls sont également composés de servces. Le beson pour la moblté des spécfcatons entre dfférentes plate-formes et outls A l heure actuelle, l exste un grand nombre de propostons et standards qu concernent la spécfcaton des servces Web. Nous allons nous ntéresser aux standards dans les sectons suvantes. Dans un premer temps, l objectf de ces standards est de proposer un langage formel pour la défnton et le rasonnement sur les servces d une manère non-ambguë. Au nveau d un servce atomque, un standard dot permettre de décrre son comportement et ses nterfaces ; l dot permettre la spécfcaton de flots de contrôle ou de comportements transactonnelles quand l s agt d une composton. Une des caractérstques majeures de ces spécfcatons standards concerne la moblté des spécfcatons entre les dfférents outls, plate-formes et entreprses. Cec est une conséquence secondare de leur structure basée sur XML. Dans un envronnement caractérsé par l ouverture, la normalsaton et la concurrence, le commerce électronque permet de dématéralser les flux dnformaton qu composent les échanges 22

39 3.2. L approche orentée servce et ses technologes : Le dogme nter-entreprses et accélèrent ans les transactons en les automatsant et en rédusant leurs coûts. Mas l faut des ntérêts communs et une volonté partagée pour mettre en oeuvre des échanges nter-entreprses. Il faut auss dsposer de normes et de standards pour partager des données décrtes dans un vocabulare compréhensble par tous les partenares mplqués. C est là le fondement des modèles normatfs orentés échanges de données (EDI) qu ont démontré leur valdté malgré une complexté et un temps de mse en oeuvre qu a lmté leur déploement aux grandes entreprses et à leur fournsseurs. Pour mplquer les PME dans ces chaînes d échanges, d autres normes, plus smples à mplémenter et adaptées à l Internet, sont aujourd hu proposées. Le format d échange qu fat l unanmté repose sur XML, plus smple, plus flexble et plus nteropérable que les formats EDI EDIFACT (en Europe) ou X.12 (au États-Uns). Malgré cet effort, le taux de pénétraton de l EDI de génératon XML reste fable et a des dffcultés à convancre. Les rasons sont multples, parm lesquelles on peut cter : Une rgdté des offres très vertcalsées (catalogue et processus d achats, appels doffres) dentque à celle du monde EDI, Une valeur ajoutée nsuffsante pour justfer l équpement ou le remplacement d un exstant EDI, Allant dans le sens de la valeur ajoutée, des projets beaucoup plus ambteux ont vu le jour tels que ebxml de l OASIS et l UN/CEFACT (organsme des Natons Unes à l orgne de EDIFACT). Ces projets complètent le modèle EDI en terme d nteropérablté et de couverture fonctonnelle, mas ne rédusent pas réellement les coûts et délas de mse en œuvre de par leur complexté et leur côté fortement normatf. Pour ces rasons les servces Web trouvent également leur place dans un contexte de mse en œuvre d échanges B2B car ls apportent une alternatve très peu contragnante aux entreprses et une mplémentaton mons coûteuse compatble avec la démarche d expérmentaton. Les servces Web sont ans une étape pragmatque vers la mse en œuvre de solutons de type ebxml en permettant aux entreprses de préparer leur système d nformaton aux futures normes d échanges B2B. Le système d nformaton de la plupart des entreprses est hétérogène et reflète l évoluton technologque des qunze dernères années : du manframe au clent/serveur pus du clent/serveur au Web. Dans ce contexte, de plus en plus de projets «transversaux» voent le jour allant de smples besons d échange de données entre applcatons jusqu aux collaboratons étrotes de ces applcatons au sen de procédés méters. Pour répondre à ces besons ont été conçues les plates-formes d EAI (Enterprse Applcaton Integraton), outls d nfrastructures logcelles qu, sans remse en cause de l exstant, permettent d en assurer l ouverture et la flexblté. Les servces Web permettent de franchr une nouvelle étape en proposant un modèle d archtecture adapté à ces besons Technologes relatves basées sur XML Dans cette secton, nous dscutons les technologes lées à la réalsaton des servces Web. Par la sute, nous présentons la problématque lée à la composton des servces ans que les standards correspondants. Les servces Web dstnguent pluseurs nveaux d mplémentaton et de technologes correspondantes. Le premer nveau couvre les fonctons mnmales de publcaton, découverte et lason de servces. Les spécfcatons présentées sont fondés sur XML (extensble Markup Language) [W3C]. XML est un standard de représentaton de données sem-structurées. Dans un document XML, la structure des données est fourne par le bas de l utlsaton de balses (comme en SGML Standard Generalzed Markup Language [Goldfard1990], mas en s affranchssant des aspects lés à la présentaton des données). Cette structure n est pas auss rgde que celle d une base de données relatonnelle par exemple. Dans un document XML, les données peuvent être défnes selon un schéma, mas cela n est pas oblgatore et le schéma peut 23

40 Chaptre 3. Etat de l art Composton Qualté de servces Aspects non fonctonnels WS BPEL WS Relable Messagng WS Atomc Transacton WS CDL WS Securty WS Trust Descrptons WSDL WS Polcy Messagng Soap, Attachment WS Adressng Transport HTTP, SMTP, TCP/IP Fg. 3.1 Les exemples de technologes et de standards des servces Web lasser quelques partes partellement spécfées. XML que nous avons explqué brèvement c-dessus, est utlsé à pluseurs nveaux. La descrpton de l nterface d un servce Web va permettre d apporter les nformatons technques sur le servce. Ces descrptons seront échangées entre les dfférents acteurs pour qu ls pussent prre connassance de ces nformatons technques, étape préalable et nécessare à l ntégraton des servces dans le système d nformaton. WSDL WSDL (Web Servces Descrpton Language)[Chnnc et al.2002] est un langage de la famlle XML permettant de décrre les types des données echangées et les fonctons fournes par un servce Web. L objectf est de fournr la descrpton des servces ndépamment de leur mplémentaton sous une forme que des personnes ou des programmes peuvent nterpréter. Pour cela, WSDL joue un rôle prmordal dans les technologes de servces Web. Les descrptons WSDL sont en fat équvalentes à des méthodes publques d une classe Java. La défnton de WSDL est composée de deux partes : La descrpton abstrate et la descrpton concrète. La parte abstrate content la défnton des messages qu peuvent être reçus et fourns par le servce et la sgnature des opératons supportées sans aucune consdératon sur la technologe utlsée pour effectvement mplémenter le servce (.e. où le servce est dsponble physquement). La parte concrète de la défnton du WSDL décrt ce que fat un servce en termes de messages échangés. Dans un premer temps, l objectf de ce nveau est de décrre comment formater les messages pour nteragr physquement avec un servce donné. Elle content essentellement l ndcaton du protocole utlsé pour échanger des messages avec le servce (SOAP au-dessus de HTTP) et les assocatons entre la descrpton de l nterface abstrate du servce et les types de messages supportés par le protocole de communcaton sous-jacent (par exemple SOAP). La producton d une descrpton WSDL qu correspond à une applcaton logcelle est une tâche fastdeuse dont le développeur peut être déchargé par l utlsaton d outls pour la génératon automatque de la descrpton WSDL. L exemple par excellence peut être un outl qu 24

41 3.2. L approche orentée servce et ses technologes : Le dogme pr en entrée la descrpton du servce d une classe Java ou d un objet COM et fournt la descrpton équvalente en WSDL en sorte. La deuxème verson de WSDL (WSDL 2.0) nclut des fonctonnaltés que la premère verson ne supporte pas. Comme synthèse de WSDL, on peut noter les ponts suvants. WSDL décrt essentellement l accessblté d un servce et pas qu est-ce que le servce peut fare. WSDL ne décrt pas comment un servce effectue le servce. La technologe de base de la couche communcaton des servces Web est le protocole SOAP. Ce protocole permet de mettre en oeuvre deux types d échanges : le mode RPC (Remote Procedure Call) et le mode message/document. Un certan nombre de technologes complémentares permettent de gérer plus fnement le routage des messages dans une nfrastructure réseau, ans que la sécurté. SOAP Les nteractons entre servces Web s effectuent par le bas d envos de messages structurés au format XML. Le protocole SOAP (Smple Object Access Protocol) [Box et al.2000] fournt le cadre permettant ces échanges. SOAP est orgnellement ssu de tentatves précédentes vsant à standardser l appel de procédures à dstance, et en partculer de XML-RPC [Wner 1999]. Mas à la dfférence des technologes RPC, SOAP n est pas fondamentalement lé à la noton d appel de procédure. En effet, SOAP vse à faclter l échange de messages XML, sans se lmter à des messages dont le contenu encode des paramètres d appel de procédure et sans favorser des échanges bdrectonnels de type requête-réponse comme c est le cas des protocoles RPC. Dans le jargon des servces Web, SOAP permet d encoder des nteractons orentées-rpc mas auss des nteractons orentées-document. Une autre caractérstque de SOAP est de fare abstracton de la couche de transport sous-jacente. Ben que la pratque la plus répandue sot d utlser SOAP au-dessus de HTTP, l exste auss des mplantatons de SOAP au-dessus d autres protocoles tels que le protocole d échange de messages électronques SMTP, et les protocoles de transport orentées-message de Mcrosoft et IBM, à savor MSMQ et MQSeres respectvement. La manère d mplanter SOAP au-dessus d un protocole de transport donné est appelée une lason SOAP (<SOAP bndng > en anglas). Une lason SOAP défnt, en partculer, l encodage des messages (nécessare en partculer lorsque le protocole sous-jacent utlse un format bnare), la méthode pour l échange de messages, l encodage des noms d opératons (appelés <SOAP Actons >), et la façon dont dfférents messages (y comprs les messages d erreur) appartenant à la même nteracton sont corrélés. Par exemple, la lason SOAP au-dessus de HTTP défnt que les messages sont encodés dans un < type de méda > appelé < applcaton/soap+xml > (c est-àdre en XML avec quelques extensons), que le nom de l opératon correspondant à une requête est donné dans une en-tête HTTP appelée <SOAPActon >, et que les messages dans une nteracton sont échangés au travers des méthodes POST et GET fournes par HTTP. D autres règles (dont nous ne donnons pas les détals) défnssent la manère dont les messages appartenant à un même échange (y comprs les messages d erreur) sont corrélés en explotant les caractérstques des méthodes POST et GET. Outre la défnton du moyen des messages en fasant abstracton de la couche de transport, SOAP défnt une structure standard de messages dans laquelle le contenu des messages est séparé des méta-données lées à l échange des messages. Ans, un message SOAP est consttué de deux partes : un en-tête et un corps. L en-tête ndque l objet du message (l appel d une opératon ou le retour de résultats), la descrpton de l expédteur, et l nformaton requse pour achemner le message au destnatare. Le corps du message peut contenr : () un document quelconque ; () l appel d une opératon offerte par le servce destnatare, avec les valeurs pour les paramètres d entrée ; () les valeurs produtes en résultat d une appel ; ou ben (v) un message d erreur. Ans, SOAP offre dverses possbltés d nteractons entre les servces : 25

42 Chaptre 3. Etat de l art sot des échanges de documents, sot des nteractons de type RPC. Il exste pluseurs mécansmes pour construre, analyser, et échanger des messages SOAP dans des langages varés tels que Java, C++, Perl, C, etc. Ces mplantatons permettent de générer les en-têtes de messages SOAP et de mettre en correspondance le contenu du corps du message avec les structures de données défnes dans le langage. UDDI Une problématque généralement assocée à la descrpton de servces est celle de leur publcaton et leur découverte. Un standard proposé pour s attaquer à cette problématque est UDDI [Draft]. UDDI défnt une nterface de programmaton pour publer des descrptons de servces dans des répertores dédés, pour soumettre des requêtes à base de mots-clés sur ces répertores et pour navguer au travers des descrptons obtenues par le bas de ces requêtes. Etant donné l exstence de moteurs de recherche sophstqués auss ben pour des Intranets qu au nveau de l Internet tout enter, ans que l exstence d autres technologes pour geston de répertores telles que LDAP [Koutsonkola and Vakal2004], la valeur ajoutée apportée par UDDI est dffcle à dentfer [Dumas and Fauvet2006]. Par conséquent, nous ne détallons pas UDDI dans l état de l art comme l est plutôt lé à la découverte des servces et pas à leur composton La composton des servces La composton des objets, des modules logcels et même des procédés méters est, un sujet d étude actuel depus de nombreuses années pant lesquelles les développeurs ont créé de nombreuses propostons de langages et de systèmes. Pourtant, aucune proposton à jour n est conçue pour être utlsée dans le contexte des archtectures orentées servces. Les archtectures orentées servces exgent de nouvelles approches qu pour maîtrser, les nteractons entre des enttés fablement couplées, la composton dynamque sur demande, les changements fréquents tels que la localsaton, la dsponblté, les qualtés de servce, et la manque de contrôle sur la plate-forme et l mplémentaton des servces composés. Dans un tel contexte, pluseurs exgences ont été dentfées pour un modèle de composton déal : L ntégraton flexble : Le modèle de composton dot être suffsamment rche pour exprmer les scénaros que les organsatons partenares veulent mplémenter. Plus mportant, le modèle dot s adapter rapdement aux changements des servces qu l compose. La composton récursve : Fournr un procédé méter comme un servce dot permettre de représenter pluseurs vues du même servce aux dfférents clents. La séparaton et la composton des préoccupatons : En consdérant la composton des servces dans une plate-forme, la logque du procédé méter dot être découplée des mécansmes secondares telles que la qualté de servce, la coordnaton des protocoles et les messages. Les conversatons et la geston du cycle de ve : La composton dot défnr le cycle de ve dans lequel les nteractons conversatonnelles sont ntégrées. La geston des échecs : Les modèles de composton ont beson de systèmes de geston d échecs pour détecter et gérer les exceptons pant la pérode de concepton et d exécuton. Les efforts de standardsaton concernant la composton des servces sont structurées autour de deux approches essentelles. La fgure 3.3 llustre l évoluton des standards. La premère approche qu sut l approche centralsée du workflow s appelle Orchestraton. La deuxème ap- 26

43 3.2. L approche orentée servce et ses technologes : Le dogme op 1 op 8 op 9 a 1 op 2 op 3 a 2 a 3 op 4 op 5 a 4 a 5 op 6 op 7 Fg. 3.2 Exemple d orchestraton proche qu est plus récente et en conséquence mons comprse est la Chorégraphe. Ces deux approches peuvent être présentées comme c-dessous. Orchestraton L objectf de l orchestraton est de défnr une spécfcaton de la composton d un pont de vue d une entté centralsée qu exécute la spécfcaton et effectue la coordnaton des servces. Comme soulgné dans les sectons précédentes, c est la vson de l approche workflow classque. Selon l approche orchestraton, une composton est spécfée en un langage mpératf décrvant les dépances de contrôle et de donnée des actvtés. Les actvtés sont des nvocatons des servces composés. La fgure 3.2 llustre un exemple d orchestraton où la coordnaton des servces composés (Servce 1, Servce 2, Servce 3) est effectuée par un servce (Servce composé). La composton consdère cnq actvtés (a 1, a 2, a 3, a 4, a 5 ) et leur dépances de contrôle. Les actvtés correspondent aux nvocaton des opératons appartenant aux servces composés. L orchestraton peut être mplémentée en utlsant les spécfcatons exstantes et standards tels que WS-BPEL (Web Servces - Busness Process Executon Language)[OASIS2005]. WS-BPEL est un des standards prometteurs. Dans le reste de cette secton, nous présentons l approche orchestraton en utlsant WS-BPEL. Connu sous le nom BPEL4WS(la premère verson BPEL4WS V1.0 date de jullet 2002 et a été proposée par BEA Systems, Inc. IBM Corporaton et Mcrosoft), renommé WS-BPEL par la sute, cette spécfcaton s appelle auss BPEL. Hstorquement, cette verson état la fuson 27

44 Chaptre 3. Etat de l art ½º¾ºÄ³ Ö Ù Ù Ò ÈÖÓ Å Ò Ñ ÒØ ÈÅ º½½ ÚÓÐÙØ ÓÒ Ø Ò Ö Ð ÑÓ Ð Ø ÓÒ Ø Ð³ Ü ÙØ ÓÒ ÔÖÓ Ñ Ø Ö Ú Ö ÓÒ Ð Ô Ø ÓÒº È Ä ØÙÒÐ Ò Ô ÖÑ ØØ ÒØ ³ ÜÔÖ Ñ ÖÐ³ Ü ÙØ ÓÒ ³ÙÒÔÖÓ Ù Ò ÈÖÓ Ü ÙØ ÓÒÄ Ò Ù ÓÙÚ ÒØ ÔÔ Ð È Ä ÏËÓÙ ÒÓÖ ÏË¹ È Ä ÐÓÒÐ Ô ÖØ Ò ÒØ Ò Ð ÓÒØ ÜØ Ð³ ÚÓÐÙØ ÓÒ ØÙ ÐÐ ÈÅº ØÓÒ ³ ÓÖ Ð Ø Ò Ö È Ä È ÖÑ ØÓÙØ Ð ÔÖÓÔÓ Ø ÓÒ Ü Ø ÒØ ÒÓÙ ÔÓÙÚÓÒ Ø Ö ÐÐ ÕÙ ÒÓÙ Ñ Ð ÒØÐ ÔÐÙ Û ÖÚ º Ð Ò Ù Ø Ð ÔÖ Ñ Ö ØÖ Ò ØÔ ÖÐ ÓÖ Ò Ñ Ø Ò Ö Ø ÓÒºÄ Ö ÓÒ Ø ÑÔÐ ³ ØÐ Ð Ò Ò Ú Ù ÔÓÙÖ ÜÔÖ Ñ ÖÐ³ Ü ÙØ ÓÒ ³ÙÒÔÖÓ Ñ Ø Öº Ø ÓÒ ÔÙÖ Ñ ÒØ Ö Ô ÕÙ Ø ÓÔØ Ù ÕÙ³ ÓÙÖÔ ÖÔÐÙ ¾ ÈÅË ÓÒ ÓÖÑ Ñ ÒØ ÙÜ Ø Ø Ø ÕÙ Ð ÈÅÁ ØØÔ»»ÛÛÛº ÔÑÒºÓÖ» Ù¾ ÚÖ Ö¾¼¼ µºä ÒÓØ Ø ÓÒ ÈÅÆ Ö ÔÖ Ò Ð ÔÖ Ò Ô Ù Ù Ò ÈÖÓ Å Ò Ñ ÒØ Ø ÛÓÖ ÓÛ Ò ³ ÔÔÓÖØ ÖÙÒ Ö ¹ ÈÐÙØ Ö Ð Ô Ø ÓÒ ÈÅÆ½ ÙØÔÖÓÔÓ Ô ÖÐ³ÇÅ ¾ ØÐ ÈÅÁ Ò¾¼¼ º ØØ ÒÓØ ¹ ÔÖ ÒØ Ø ÓÒÚ Ù ÐÐ Ü Ù Ø Ú ØÓÙ Ð Ô Ø ÓÒ ÔØÙ Ð Ù ÈÅºÍÒØ Ð Ø Ò Ö Ô ÖÑ Ø ÙÜÓÒ ÔØ ÙÖ ÔÖÓ Ñ Ø Ö ÓÑÔÖ Ò Ö ÑÙØÙ ÐÐ Ñ ÒØØÖ Ú Ö ÙÒ Ö ÔÖ ÒØ Ø ÓÒ Ö Ô ÕÙ ÙÒ ºÄ ÙÖ ½¾ ÐÐÙ ØÖ ÙÒ Ü ÑÔÐ ÔÖÓ ÒÒÓØ Ø ÓÒ ÈÅÆº Fg. 3.3 Evoluton des efforts de standardzaton de deux propostons antéreures fates par IBM et Mcrosoft qu s appelaent respectvement Web Servces Flow Langugage, WSFL [wsf] et XLANG [Thatte2001]. En 2003, la verson 1.1 de BPEL est soumse à OASIS (Organzaton for the Advancement of Structured Informaton Standards) pour devenr un standard. Actuellement, une nouvelle verson (verson WS-BPEL 2.0) est en cours de défnton. WS-BPEL est un langage de workflow extensble qu spécfe les nteractons des servces. La composton des servces avec BPEL est récursve parce qu une composton expose des nterfaces WSDL, et que cette nterface peut être utlsées d autres compostons. BPEL est conçu pour être utlsé dans des envronnements dynamques dans lesquels les servces composés peuvent rapdement changer. BPEL utlse les nveaux placés en dessus des WS spécfcatons ans que WSDL. Par exemple, en utlsant XPath, les données de BPEL peuvent être accédées et manpulées. De même, les références des servces composés peuvent être dynamquement changées sous forme de WS-Addressng. Avec l extensblté de BPEL, un concepteur de composton peut Rejected attacher des aspects addtonnels comme la qualté de servce exgée avec WS-Polcy et WS- PolcyAttachements. En BPEL, la logque des nteractons entre un servce et son envronnement est décrte par le bas d une composton d actons élémentares de communcaton (émsson, récepton ou émsson/récepton). Ces actons sont relées les unes aux autres par un flot de contrôle exprmé par le bas de constructons telles que la composton parallèle (avec un nombre fxé de branches), séquentelle, et condtonnelle, des règles de type événement-acton et des clauses de capture/transmsson d erreur. La manpulaton des données s effectue par le bas de varables, comme dans un langage de programmaton mpératve. Plus précsément, un processus exprmé en BPEL est construt à partr d actvtés prmtves qu peuvent être composées pour défnr d autres actvtés plus complexes. Les actvtés prmtves sont : la récepton (receve) qu bloque Accepted or Receve Order Rejected? Shp Order Accepted Fll Order Close Order Ù Ð Ð³ Ô Ø Ö Ô ÕÙ Ó Ö ÒØÙÒ ÒÓØ Ø ÓÒ Ö Ö Ò Ô ÖÑ ØØ ÒØÐ ØÖ ÙØ ÓÒ º½¾ Ü ÑÔÐ ÔÖÓ ÒÒÓØ Ø ÓÒ ÈÅÆ S Invoce Make Payment Accept Payment ÙØÓÑ Ø ÕÙ ³ÙÒÔÖÓ ÑÓ Ð Ö Ô ÕÙ Ñ ÒØ Ò ÙÒ ÓÖÑ ØÓÑÔÖ Ò Ð Ô ÖÙÒÑÓ¹ Ø ÙÖ ³ Ü ÙØ ÓÒ ÔÖÓ Ð ÒÓØ Ø ÓÒ ÈÅÆ ÙÔÔÓÖØ ØÓÙ Ð ÛÓÖ ÓÛÔ ØØ ÖÒ Ö Ò ½ ÈÅÆ Ù Ò ÈÖÓ ÅÓ Ð Ò ÆÓØ Ø ÓÒ ¾ÇÅ Ç ØÅ Ò Ñ ÒØ ÖÓÙÔ ÈÅÁ Ù Ò ÈÖÓ Å Ò Ñ ÒØÁÒ Ø Ø Ú ¾ l exécuton jusqu à l arrvée d un message correspondant à une opératon ; l appel (nvoke) et la réponse (reply) qu chacune effectue un envo de message correspondant à une opératon ; l affectaton (assgn) qu assoce une expresson (décrte en XPath ou XSLT) à une varable ; l attente (wat) qu bloque l exécuton pour une pérode de temps fxée ; la transmsson (throw) d erreur et la fn (ext) pour termner l exécuton. La plupart des opérateurs de composton proposés par BPEL correspondent à ceux déjà présents dans les langages de programmaton mpératve : la séquence (sequence) pour mposer un ordre dans l exécuton, le chox (swtch) pour exprmer un branchement condtonnel, et l tératon (whle). Le concept de bloc ssu des langages de programmaton structurée est présent dans BPEL par le bas de la noton de portée (scope). En plus de ces opérateurs de composton, BPEL offre pluseurs constructons pour la programmaton concurrente : la composton parallèle (flow) pour exécuter pluseurs actvtés en parallèle ; la sélecton (pck) pour chosr un message parm pluseurs entrants ou les tmers ; des dépances de précédences (lnk) peuvent être défnes entre des actvtés qu autrement 28

45 3.2. L approche orentée servce et ses technologes : Le dogme s exécuteraent en parallèle. Fnalement, des règles de type événement-acton (event handlers) peuvent être assocées à des blocs (scope). Ces règles sont déclenchées par la récepton d un message ou l expraton d un déla, à n mporte quel moment au cours de l exécuton du bloc correspondant. Dans le langage BPEL, tout est servce : un processus exécutable est l mplantaton d un servce qu s appue sur d autres servces. Lorsqu une ressource, telle qu une base de données, un fcher, ou une applcaton patrmonale, est utlsée par un servce, l est nécessare d exposer le SGBD, le système de geston de fchers, ou l applcaton comme un ensemble de servces. Pour pouvor utlser BPEL dans des envronnements où toutes les ressources ne sont pas forcément exposées comme des servces, l est quelques fos judceux de casser le paradgme tout servce de BPEL. C est dans cet esprt qu a été défne BPELJ [Blow et al. 2004], une extenson de BPEL avec laquelle l est possble d ntégrer des bouts de code Java dans un programme BPEL. Cette approche est smlare à celle des JSPs (Java Server Pages) où du code Java est embarqué dans des programmes HTML. La consdératon de BPEL dans les deux plates-formes.net et Java lasse à penser que d autres dalectes proches de BPEL vont émerger. BPEL est aujourd hu un standard de facto pour mplanter des servces Web selon un pont de vue orentée procédé. Des plates-formes matures et reconnues, telles que BEA WebLogc, IBM WebSphere, Mcrosoft BzTalk, SAP XI et l outl de geston de procédé BPEL d Oracle supportent BPEL à des degrés dvers démontrant ans l ntérêt réel de ce langage. ActveBPEL est une autre proposton assez complète dans le domane de l open source. Ben que BPEL offre des constructons spécfques pour le développement de servces Web, sa complexté pose problème. Comme le montre [Wohed et al. 2003] l opérateur lnk est dans une certane mesure redondant avec les opérateurs swtch et flow dans le sens que tout procédé BPEL écrt en utlsant swtch et flow peut être reécrt en utlsant un seul flow et un certan nombre de lnks. Auss, BPEL manque d abstractons de haut nveau lorsqu l s agt de développer des servces qu mettent en jeu des multcasts avec des condtons de synchronsaton partelles, comme par exemple dans le cas d un servce clent qu requert des devs de pluseurs servces fournsseurs. On peut s attre à ce que dans le futur, des efforts de recherche portent sur la résoluton de ces problèmes et proposent sot des extensons de BPEL, sot des langages alternatfs. Chorégraphe La deuxème approche essentelle pour la composton de servces Web est l approche chorégraphe. L approche chorégraphe consdère une exécuton décentralsée avec des nteractons P2P entre les servces composés. Comme explqué dans la spécfcaton du Consortum World Wde Web (W3C) qu a publé le premer document de traval du Langage de Descrpton de Chorégraphes pour les Servces Web, un des objectfs des servces Web est la composton pour rédure leur coût de connectvté et optmser l utlté et, par conséquent, la valeur de l nformaton. Selon l approche orchestraton, la seule manère d ntégrer des servces a conssté à les connecter en couplant des ponts d ntégraton ou en utlsant du code mpératf comme une spécfcaton WS-BPEL. La chorégraphe, grâce à un modèle global, garantt un comportement contractuel entre servces multples sans recours à aucun couplage centralsé. Il est à noter qu un autre objectf des servces Web est la conformté tels que l ntégraton d applcatons de manère à partager les mêmes règles d engagement, afn de garantr le résultat souhaté. Ans, les servces bénéfcent d une mse sur le marché plus rapde grâce à une chorégraphe ben défne garantssant la conformté entre domanes d applcatons. Il peut être démontré statstquement qu une chorégraphe est exempte de tout nterblocage. Cela veut dre que les procédés des servces s arrêtent, chacun attant l un des autres, de cycle non productf (les procédés nteragssant contnuellement sans réalser de tâches utles) et de futes (nterférences de partcpants non au- 29

46 Chaptre 3. Etat de l art torsés). L absence de futes accroît la sécurté entre servces connectés. L absence d nterblocages et de cycles non productfs rédut les coûts de tests, et donc le coût total d appropraton. Dans ce groupe, on peut donner comme exemple le langage WS-CDL [W3C2005]. Ce langage permet de spécfer les nterfaces de servces Web pour réalser une chorégraphe. La collaboraton se passe alors dune manère décentralsée, sans utlser un procédé prncpal, mas plutôt pluseurs procédés dstrbués. La spécfcaton WS-CDL défnt la collaboraton pont-à-pont entre servces Web partcpants. Un clent de servce Web, automatsé ou non, peut être un autres servce Web, une applcaton ou un être human. Dans WS-CDL, un ensemble d nteractons clentes peuvent être assocées dans le temps dans un «groupe de collaboraton». Ce derner est, par exemple, un ensemble de composants mplqués dans une opératon commercale ou une transacton de base de données. Le futur des applcatons de commerce électronque résde dans le couplage lâche et le caractère décentralsé du World Wde Web. Cet envronnement requert la possblté de réalser des collaboratons pont-à-pont durables entre servces partcpants, dans ou à travers les domanes de confance d une organsaton. Les applcatons mplémentant WS-CDL peuvent attendre ce but commun, le groupe de traval ayant développé son caher des charges en prenant en compte un large ensemble de besons commercaux concrets ans que de soldes théores. La spécfcaton WS-CDL regroupe des connassances mportantes du monde des entreprses et de la recherche. WS-CDL ntrodut non seulement les besons des entreprses, mas auss les travaux mathématques sémnaux sur le π-calcul, algèbre fondée sur la noton d nteracton et le mécansme de nommage, et utlsée pour modélser des systèmes physquement ou vrtuellement mobles. En conséquence, la chorégraphe défnr les nteractons des servces d un pont de vue décentralsé comme llustré dans la fgure Synthèse sur l approche orentée servce L essor de l Internet a perms de fare émerger de nouvelles perspectves dans la mse en place de collaboratons entre organsatons de toutes sortes (commercales, gouvernementales ou ndvduelles). La réutlsaton des servces accessbles par l Internet en les composant afn d en construre de nouveaux, avec valeur ajoutée, est l une de ces perspectves les plus prometteuses. Les servces Web sont une technologe à part entère, dont le pérmètre d applcaton très vaste ouvre de réelles opportuntés au sen du système d nformaton des entreprses. Ben que la technologe de servces Web ne sot pas la seule soluton pour réalser les archtectures orentées servces, elle est la technologe essentelle consdérée par l ndustre. Avec des servces Web, l ndustre adresse encore une fos le déf fondamental de l nformatque réparte : comment fournr une manère unforme de décrre des composants ou des servces dans un réseau, de les localser, et de les accéder? L ndustre aborde ce problème en utlsant la technologe et caractérstques qu sont développées d une voe ouverte, utlsant des assocatons d ndustre et de larges consortums. Les systèmes d nformaton qu peuvent bénéfcer des apports de la technologe des servces Web sont nombreux. Parm les prncpaux crtères qu permettent de les dentfer on trouve les besons suvants : la mse à dsposton des partenares de servces lés au cœur de méter d une entreprse, pour permettre d élargr le réseau de dstrbuton et de créer des offres conjontes plus attractves en explotant effcacement les synerges que relent chacun des acteurs, la commercalsaton d offres ASP (Applcaton Servce Provder) conçues pour permettre une étrote ntégraton avec le système d nformaton des clents, la défnton de pratques et servces méters partagés au sen d une communauté nterprofessonnelle, fédérés par un annuare, la mse en œuvre d échanges commercaux avec flexblté et fable nvestssement, 30

47 3.2. L approche orentée servce et ses technologes : Le dogme P 1 P 2 P 3 Fg. 3.4 Exemple de chorégraphe les besons d échanges entre applcatons dans un système d nformaton hétérogène, la mse en œuvre de servces applcatfs réutlsables et ndépants des évolutons du système d nformaton, la normalsaton des nterfaces d accès aux sources d nformaton et référentels de données, l ntégraton d applcatons, pour les besons nternes (Applcaton-to-Applcaton, A2A) et externes (Busness-to-Busness, B2B), Cette lste n est pas exhaustve, mas explque l mportance crossante des servces Web au sen des offres méters (progcels...) et d nfrastructure (serveurs d applcatons, EAI...). Cette adopton massve est amplfée par un cycle d apprentssage très court de la technologe des servces Web. Les démarches d étude et de mse en œuvre sont dans la contnuté de celles utlsées pour les archtectures à base d objets dstrbués (CORBA, J2EE,.NET), et utlsent en partculer UML (Unfed Modelng Language). Les technologes de développement ne sont pas remses en cause (les outls de développement de servces Web sont souvent des compléments aux atelers de développement habtuels). La plate-forme technologque des servces Web n est pas totalement achevée ; cela dot être nterprété comme une opportunté et confrme l évoluton du modèle vers une nfrastructure complète et cohérente capable d apporter les nveaux de servces ndspensables pour couvrr le cycle de ve des systèmes d nformaton : l nterface clent pour le développement des applcatons clentes et des IHM (nterfaces homme-machne), les mèthodes pour l orchestraton des procédés méters, la geston des transactons et des compensatons, 31

48 Chaptre 3. Etat de l art les regstres pour l annuare des servces et la geston de leur cycle de ve, les composants pour la concepton et la réalsaton des servces méter, la communcaton pour les servces de transport et de sécurté, l admnstraton pour les outls et servces d admnstraton, de déploement et de supervson, Les plates-formes de développement et de déploement de servces Web convergent aujourd hu vers ce modèle et couvrent un sous-ensemble mportant de ces fonctonnaltés. Les mplémentatons dsponbles sont de bonne facture, nteropérables entre elles grâce notamment à la dsponblté d mplémentatons Open Source de référence, et permettant la réalsaton d applcatons servces Web opératonnelles au sen des entreprses. Les servces Web sont ndénablement un nouvel atout pour l entreprse étue. On peut clarement constater que la technologe des servces Web répond aux exgences essentelles de la programmaton des systèmes dstrbués. Pourtant, soulgnons auss que les problèmes relatfs aux compostons des servces tant pour le composton fonctonnelle que la composton vs-à-vs des aspects non-fonctonnels sont complexes. 3.3 Systèmes d nformaton décentralsés et par-à-par Les systèmes d nformaton, réalsés en employant des archtectures logcelles orentées servces ou d autres technologes, reposent sur des nfrastructures matérelles dspersées dans l espace. Ces nfrastructures ont dfférentes caractérstques les dstnguant les uns des autres. Les systèmes décentralsés et P2P ont pour but la mse en place des nteractons drectes entre les partcpants (personnes, machnes ou systèmes de gestons de procédé méter) d un système d nformaton. Tant d un pont de vue organsatonnel que technque, la problématque des systèmes décentralsés et surtout par-à-par est très actuelle. Dans cette secton, nous donnons une défnton de notre compréhenson de décentralsaton et de P2P. Nous allons examner les caractérstques représentatves de ces systèmes, sot par leur nfluence hstorque sur l évoluton du paradgme, sot par l mportance qu elles prennent par rapport aux exgences des systèmes d nformaton. Les nfrastructures dstrbuées dtes P2P sont essentellement conçues pour le partage de ressources d nformatons (contenu, stockage, cycles d unté centrale de tratement) par l échange drect, plutôt que d exger l ntermédare ou l appu d un serveur ou d une autorté centralsé [Androutsells-Theotoks and Spnells2004]. Ces nfrastructures connassent un très grand succès depus 1999, date à la quelle Napster, une applcaton P2P de partage de fchers a perms le partage lbre des fchers multmédas entre les utlsateurs volontares de l applcaton. Sute à l arrêt du Napster qu n est pas formellement une applcaton P2P pusqu l repose sur l utlsaton d un serveur centralsé, un autre groupe de développeurs a réalsé une autre applcaton de partage de fcher smlare à Napster mas qu est complètement dstrbué, échappant ans à tout contrôle [Doyen2005]. Cette applcaton, Gnutella, montra qu l est possble de fournr un servce partculer à une communauté sans se baser sur une nfrastructure physque concrète. Cette bonne proprété est la rason prncpale de l attenton partculère portée aux systèmes P2P. S les premères applcatons de l approche P2P étaent exclusvement lées à l échange souvent llégal des fchers multmédas soums à des drots d auteur, actuellement, l ensemble des systèmes d nformaton sont repensables et repensés pour être déployés selon une approche P2P. Dans la lttérature, on trouve pluseurs défntons qu décrvent la noton P2P. C-dessous, nous donnons quelques défntons de la noton P2P qu soulgnent ses dfférentes caractérstques. 32

49 3.3. Systèmes d nformaton décentralsés et par-à-par 1. Dstrbuted computer archtectures labeled peer-to-peer are desgned for the sharng of computer resources (content, storage, CPU cycles) by drect exchange, rather than requrng the ntermedaton or support of a centralzed server or authorty. Peer-to-peer archtectures are characterzed by ther ablty to adapt to falures and accommodate transent populatons of nodes whle mantanng acceptable connectvty and performance. [Androutsells-Theotoks and Spnells2004] 2. Peer-to-peer s a class of applcatons that take advantage of resources (storage, cycles, content, human presence) avalable at the edges of the Internet. Because accessng these decentralzed resources means operatng n an envronment of unstable connectvty and unpredctable IP addresses, peer-to-peer nodes must operate outsde the DNS and have sgnfcant or total autonomy of central servers [Schollmeer2001]. 3. A dstrbuted network archtecture may be called a Peer-to-Peer network, f the partcpants share a part of ther own hardware resources (processng power, storage capacty, network lnk capacty, prnters,...). These shared resources are necessery to provde the Servce and content offered by the network. They are accessble by other peers drectly, wthout passng ntermedary enttes. The partcpants of such a network are thus resource provders as well as resource requestors [Than et al.2005]. De ces défntons, un certan nombre de caractérstques peuvent être développées pour décrre les systèmes P2P. Nous nous ntéressons à ces caractérstques dans le reste de cette secton. Caractérstques des systèmes P2P Dans cette parte, nous présentons les caractérstques typques des systèmes décentralsés et systèmes égal-à-égal ; 1. Passage à l échelle : L dée de base des systèmes P2P est de fournr un servce partculer à une communauté sur une nfrastructure décentralsée. Une des lmtatons ben connue des systèmes centralsés est le passage à l échelle comme une entté centralsée peut devenr faclement un goulot d étranglement [Kng1983] [Sheth and Kochut1997] [Chen and Hsu2001] d un pont de vue de performance. En effet dans les systèmes centralsés, une entté centralsée comme par exemple un serveur d applcaton, concentre les données des processus et les mécansmes de coordnaton des partcpants de ces derners. En conséquence, ceux-c génèrent un trafc de réseau au nveau du serveur centralsé. On peut dre sans doute que les systèmes P2P sont des systèmes à grande échelle qu gèrent un nombre d utlsateurs et des quanttés de données varants sur de grands ntervalles. Parce qu un système P2P répartt la charge ndute par des processus du système. Il est à noter que la geston peut être effectuée à l ade des serveurs partellement centralsés. Dans le cas où un serveur est employé pour un certan nombre de servces partculers (par exemple des servces de bootng), le nombre d utlsateurs ou la quantté de données gérés sont lmtés du fat des capactés du serveur partellement centralsé. Augmenter la capacté du servce partculer au delà de cette lmte peut entraîner alors des coûts fnancers en matérels et en logcels mportants. C est pour cette rason que les systèmes P2P qu sont partellement centralsés dovent fare un comproms entre les capactés nécessares au fonctonnement global du système et celles des serveurs centralsés. L une des possbltés d augmentaton de ces capactés d une manère ntutve est la mse en place de pluseurs serveurs qu fournssent le même servce partculer [Schuler et al.2004]. Cela pose alors le problème de la répartton de ces serveurs, de leur nterconnexon et surtout de leur cohérence. Toutefos, 33

50 Chaptre 3. Etat de l art 34 dans les systèmes P2P partellement centralsés, les charges mposées aux serveurs spécaux permettent de décharger les autres partcpants du système. 2. Dynamcté et Instablté : Les systèmes P2P permettent de représenter des échanges socaux au sens où ls lent des partcpants, utlsateurs ou machnes, qu s mplquent dans un système de manère humane. Contrarement aux systèmes dstrbuées classques, où les partcpants du système ne changent pas avec le temps, dans un système P2P, les partcpants du système peuvent changer d une manère dynamque. C est une conséquence naturelle de partage volontare des ressources par les utlsateurs de l applcaton P2P. Dans un réseau de partage de fcher comme emule [emu2002], les partcpants du système se connectent au système sans aucune ncdence sur le fonctonnement global et ls peuvent le qutter sans avor à se chercher d autres partcpants remplaçants. S on consdère les applcatons de partage de fchers, le manque des garantes transactonnelles [Gray and Reuter1993] n est pas un soucs essentel pour des partcpants. Pourtant dans les applcatons qu gèrent des procédés méter, l nstablté est une exgence essentelle [Yu et al.2004]. Toutefos, la dynamcté dont l nstablté peut être une conséquence est auss un avantage dans le contexte des procédés méter réalsés et explotés chaque jour dans les entreprses [Benatallah et al.2006] [Nezhad et al.2006]. 3. Tolérance aux pannes : Une autre conséquence de la dynamcté est la tolérance aux pannes. Dans un système d nformaton, les rasons des pannes peuvent être multples. Pour donner des exemples de pannes qu peuvent ntervenr dans un système d nformaton, centralsé ou décentralsé, on peut nommer l arrêt de partcpants du processus ou d une entté centralsé qu fournt un servce partculer. Dans un processus où une entté centralsée est employée pour fournr un servce partculer comme par exemple la coordnaton des partcpants, l exécuton correcte du processus repose ntégralement sur celle de l entté employée. S celle-c devent ndsponble, le servce qu elle fournt devent ndsponble. Dans un système purement P2P, l n exste potentellement aucun pont central de faute. S un par tombe en panne, le processus peut contnuer avec ceux qu restent. Cela llustre la sensblté des systèmes centralsés face à une panne de l entté centralsée qu assure la coordnaton des partcpants [Gauron2006]. En pratque, dans les systèmes de partage de fchers, lorsque un nœud échoue, l peut être remplacé par un autre qu fournt le même fcher partagé. Dans les procédés méters, cela n est pas toujours valable. 4. Échange drect : Une des caractérstques essentelles des systèmes décentralsés P2P est l échange drecte entre les partcpants de l applcaton. L échange drect peut s établr va un ters partcpant qu a le rôle d annuare. S un ters qu a le rôle d annuare n exste pas, les partcpants peuvent établr l échange drect par une recherche propagée dans le réseau des partcpants. L échange drect est la rason du passage à l échelle. 5. Double rôle : Un système P2P est un modèle où les partcpants jouent le rôle de clent, serveur ou un routeur pour le processus dans lequel ls sont mplqués. Un partcpant est un clent quand l consomme le produt d un servce ou d un processus exécuté par un ou pluseurs autre(s) partcpants. Un partcpant est un serveur s l fournt un servce aux autres partcpants. Un partcpant peut être consdéré comme un routeur s l fat l ntermédare entre deux partcpants qu ne peuvent pas établr une relaton drecte. Actuellement, on peut recenser pluseurs approches pour dentfer des rôles des partcpants [Park and Hwang2003] dans un système P2P. L dentfcaton des rôles peut aller des smples restrctons [Atlur et al.2001] jusqu à d autres plus sophstquées [Bertno et al.1999]. Il est à noter que la spécfcaton des restrctons concernant les rôles est ntmement lée à la topologe du système P2P. Par exemple, la satsfacton des res-

51 3.3. Systèmes d nformaton décentralsés et par-à-par trctons sophstquées comme celles du [Bertno et al.1999] [Atlur and Warner2005] peut être rréalste dans un système complètement décentralsé. Dfférents types de systèmes P2P Comme nous l avons détallé dans la secton précédente, les systèmes P2P ont pluseurs caractérstques qu les dstnguent des systèmes totalement centralsés. La caractérstque essentelle, qu motve nos contrbutons, d un système P2P est l établssement d nteractons drectes entre les partcpants. Nous détallons c-dessous les dfférentes topologes P2P dans un ordre décrossant de décentralsaton. Plutôt que dscuter les rasons qu ont poussé à leur créaton, nous détallons leur ntérêt et lmtes respectfs ans que leur caractère complémentare. 1. Systèmes P2P basés sur des enttés centralsées : Ce type de systèmes est le premer exemple de systèmes P2P. La premère applcaton de ce type est Napster [Carlsson and Gustavsson2001 qu vu le jour en jun Conçu pour partager des fchers multmédas, l s agt d un serveur ndex qu content les ttres de fchers partagés et l adresse des partcpants qu les mettent à dsposton. Lorsqu un partcpant cherche un fcher, l envoe au serveur une requête concernant sa recherche. Le serveur répond alors par une lste de partcpants hébergeant le fcher recherché. L échange du fcher se fat ensute drectement entre le partcpant qu cherche le fcher et celu qu le fournt. L ndexaton des fchers partagés et le processus de recherche qu sont les servces partculers du Napster sont fourns par une entté centralsée. En conséquence, Napster reste un système dans lequel les partcpants peuvent établr des nteractons drectes va une entté centralsée. Au delà de Napster, les avantages et les lmtes des systèmes P2P basés sur des enttés centralsées peuvent être résumés comme sut : Les servces partculers sont fourns par des enttés centralsées, qu sont responsable de les mantenr. La charge correspondant aux servces partculers est donc concentrée sur les lens attenants à l entté centralsée dans le réseau physque. Par alleurs, l se peut que le fonctonnement global du système sot lmté par d entté centralsée qu fournt les servces partculers. Il est à noter que ces modèles sont sensbles aux pannes. Cette parte de la problématque est ntutve. Parce que s l entté centralsée tombe en panne, le système P2P peut cesser de fonctonner correctement comme certans servces n exstent plus. Malgré ces lmtatons, ce modèle a des avantages. Les enttés centralsées sont asées de contrôler les servces qu elles fournssent. Dans le cas de partage lbre de fchers, ce fat peut être une désavantage comme l entté centralsée qu ndexe les fchers ou les partcpants peut censurer le servce de recherche. Mas dans les systèmes d nformaton plus sophstqués, cela est une avantage [Fakas and Karakostas2004] [Fakas et al.2003]. Pour résumer, on peut dre que les systèmes P2P qu emploent des enttés centralsées ont les mêmes avantages et lmtatons des systèmes centralsés. La topologe de ce type de systèmes est llustrée dans la fgure 3.5(c). 2. Systèmes P2P hybrdes : Chronologquement, les systèmes P2P hybrdes sont apparus après les systèmes P2P purement décentralsés. Le but essentel des approches hybrdes est de garder les bonnes proprétés des systèmes P2P basés sur des enttés centralsées en multplant celles-c afn de dmnuer les lmtatons de performance. En effet, dans ces systèmes hybrdes, les servces partculers fourns par les enttés centralsées sont réplqués ou partagés entre pluseurs enttés. Apparemment smple, le modèle hybrde cache un grand nombre de concepts et de sous-entus. On peut mmédatement constater que les systèmes hybrdes ne sont pas purement décentralsés. Ils reposent sur un nombre lmté d enttés sur lesquelles la charge totale est dstrbuée. Ces systèmes sont plus tolérants aux 35

52 Chaptre 3. Etat de l art pannes s les servces partculers sont réplqués. Dans ce cas, afn d assurer la cohérence des servces partculers, les enttés qu les fournssent dovent être synchronsés d une manère transactonnelle [Özsu and Valdurez1999]. La topologe de ce type de systèmes est llustrée dans la fgure 3.5(b). 3. Systèmes P2P purs : Les systèmes P2P purement décentralsés, conçus pour le partage des fchers, ont vu le jour après l arrêt de Napster sute à un procès. Contrarement aux systèmes P2P hybrdes ou basés sur des enttés centralsées, les systèmes P2P purs répartssent la totalté des servces entre les partcpants. Tous les partcpant ont alors le même rôle. Dans les applcatons de partage de fchers, les modèles P2P purs sont très effcaces comme ls protègent leurs partcpants en réacton aux contrôles jurdques. De cette remarque, on peut faclement dédure qu un système P2P pur est dffclement contrôlable par un ters. Ce fat est en avantage pour des applcatons de partage de fcher lorsque l peut être une lmtaton pour des applcatons plus sophstquées qu nécesstent la survellance de l un de ses partcpants. La topologe de ce type de systèmes est llustrée dans la fgure 3.5(a). (a) (b) (c) Fg. 3.5 Les topologes des systèmes décentralsés P2P Pourquo avor des systèmes décentralsés? Dans les sectons précédentes, nous avons présenté les caractérstques habtuelles des systèmes P2P et les prncpales topologes qu mértent d être mentonnées pour une melleur compréhenson de celles-c. Dans cette secton, nous allons mettre en évdence pourquo la décentralsaton et le paradgme P2P sont mportants dans un contexte plus organsatonnel au delà des applcatons de partage de fcher. Il ne s agt nullement d écrre une autre classfcaton, mas d écrre les aspects motvants de la décentralsaton. Les avantages et les lmtes exprmées sont souvent proches des caractérstques que nous avons décrtes c-dessus Des économes matérelles : Une des avantages, le plus ndénable et le plus soulgné par la communauté scentfque [Benatallah et al.2002] [Nanda et al.2004] [Alonso et al.1997] [Alonso et al.1996], des systèmes P2P est la dmnuton de coûts pour l achat et la mantenance des enttés qu jouent des rôles centralsés. Nous pouvons mettre en évdence l avantage des applcatons P2P en vue de fournr des économes matérelles avec l exemple de motvaton suvant. La fgure 3.6(a) llustre tros

53 3.3. Systèmes d nformaton décentralsés et par-à-par C C A B A B (a) (b) Fg. 3.6 La comparason de l approche centralsée et décentralsée organsatons A, B et C. L entté C a le rôle de coordnateur centralsé de la collaboraton parce qu elle route la sorte de A vers B. La fgure 3.6(b) llustre une exécuton alternatve dans la quelle la sorte de A est envoyée à B par A lu-même. Il est à noter que A et B dovent se connaître dans un contexte dynamque. Pour ce fare C dot envoyer des messages à A et à B pour qu ls pusse se coordonner. 2. Tolérance aux pannes : Une autre bonne proprété engrée par la décentralsaton est la maîtrse de la tolérance aux pannes. Dans une archtecture centralsée, la dsponblté d un servce fourn repose totalement sur la dsponblté de l entté centralsée. Dans un cas dans lequel l entté centralsée tombe en panne, le servce qu l fournt devent naturellement ndsponble. Dans un contexte P2P, l n exste potentellement aucun pont central de faute. S un partcpant dsparaît pour une rason quelconque, le servce global contnuera d être fourn par ceux qu restent. Les causes de pannes peuvent être dverses, par exemple un afflux de messages plus mportant que d habtude. Mas ces pannes peuvent être dues à des attaques prates telles que le dén de servce dont fut vctme le servce de DNS d Internet. Cela llustre la sensblté des systèmes en parte centralsé face à une charge mportante sur quelques nœuds ou les arêtes attenantes. Un système décentralsé n a en revanche aucune précauton partculère à prre vs-à-vs de nœuds spécfques, pusqu aucun nœud partculer n est nécessare à son fonctonnement. Dans ce cas, pour assurer que l on pusse toujours envoyer des messages, une soluton classque consste à vérfer régulèrement que les vosns de chaque nœud soent toujours connectés au réseau. L une des méthodes les plus utlsés pour cela est de demander à chaque vosn d envoyer régulèrement un message sgnalant sa présence. Il est auss possble d mposer aux nœuds du réseau un nombre de vosn mportant pour que la probablté qu un nœud sot déconnecté du réseau du fat de pannes de ses vosns pusse être consdérée comme néglgeable. En cas 37

54 Chaptre 3. Etat de l art 38 de déconnexon d un vosn, ses vosns le remplacent rapdement par un autre nœud, afn de dmnuer le rsque de déconnexon du réseau. En pratque, dans un système décentralsé P2P, la panne d un partcpant ou un nœud dot contnuer de fonctonner correctement tant que des partcpants y sont connectés. Même s les réseaux de partage de fchers peuvent résster au tolérance aux pannes, les systèmes décentralsés peuvent tolérer les pannes des partcpants dans une certan mesure. Un système d nformaton décentralsé peuvent se retrouver fractonné en pluseurs réseaux connectés entre eux même s certans partcpants tombent en panne. 3. Relatons équtables : Un système d nformaton, plus partculèrement, un outl de geston de procédé automatse un procédé méter au sen d une même organsaton. Comme nous l avons déjà soulgné, ces procédés s appellent des procédés ntra-organsatonnels. Le développement des technologes de l nformaton et de la communcaton facltent la collaboraton vrtuelle des organsatons et les procédés nter-organsatonnels. A l heure actuelle, la majorté des systèmes d nformaton comme des outls de geston de workflow qu automatsent des procédés nter-organsatonnels sont centralsés. L exemple par excellence de procédé nter-organsatonnel est la composton des servces Web. Une mportante lmtaton de la centralsaton est l empêchement de l établssement des relatons équtables au nveau nter-organsatonnel. Pourtant, dans bon nombre de collaboratons, ntra ou nter-organsatonnels, l exstence de la possblté de pouvor établr des relatons équtables est essentelle[port and Kaser1998] [Grnter et al.1999]. Dans une collaboraton, une relaton équtable exste s aucune des organsatons partcpantes ne contrôle les appels aux organsatons partcpants, ne dspose de la totalté des données et ne gouverne l enchaînement des actvtés. La geston centralsée d un procédé méter assume la présence d une organsaton domnante qu dspose de la spécfcaton complète de la collaboraton. Cela ne peut pas être toujours le cas. Parce que les vues de la collaboraton peuvent être mutuellement dspatchées entre les organsatons et aucune ne peut avor une vue globale[zhao et al.2005] [Port and Kaser1998]. La geston centralsée d un procédé met les organsatons partcpantes de la collaboraton dans une stuaton récessve. Parce que les partcpants contrbuent à la collaboraton d une manère solée sans savor leur rôle précs en répondant aux nvocatons reçues [Omcn and Ossowsk2004]. 4. Intéropérablté fable : Comme nous l avons détallé dans la secton précédente, l ndustre propose un certan nombre de standards pour l mplémentaton des systèmes d nformaton dont les problèmes sont relatvement complexes. Un de ces efforts est l utlsaton des standards pour établr des échanges fables entre les partcpants d une nteracton. Dans un premer temps, établr une nteracton drecte entre deux partcpants fat parte des exgences de confance [Yldz and Godart2007c]. Dans un second temps, l utlsaton des standards comme WS-Securty est plus adaptée à supporter des nteractons P2P qu ne nécesste pas un ters comme coordnateur. Consdérons l exemple suvant pour explquer la faclté d établssement drecte d une nteracton fable entre deux partcpants. C est une verson smplfée de l exemple de motvaton du deuxème chaptre. Nous consdérons une organsaton d Assurance qu fournt les servce d assurances en composant les servces fourns respectvement par l Hôptal, la Polce et l Inspecteur. Comme ndqué cdessus, les nteractons du servce Assurance avec les autres servces peuvent être supporté par un standard comme WS-Securty. Après la réclamaton d un clent, l Assurance évoque l Hôptal afn de recevor le rapport médcal du clent. Dans une telle nteracton, Assurance peut être oblgé de fare une sére de transformatons sur les données reçues. Consdérons qu après être évoqué, Hôptal fournt un rapport qu content un ensemble d nformaton

55 3.3. Systèmes d nformaton décentralsés et par-à-par relatf au souscrpteur comme par exemple les tests pathologques, les rados, les emprentes dentares, les détals de facturaton etc. Pour transférer le rapport vers la Polce, l Hôptal peut l encrypter. S le rapport peut être seulement décrypté par la Polce, l nteracton de l Hôptal et la Polce peut être consdérée comme fable même s celle-c est effectué va Assurance. Mantenant supposons que l Assurance sot ntéressée par les détals de facturaton qu sont nclus dans le même rapport. Naturellement, elle peut obtenr les détals de facturaton du rapport, s le rapport est décryptable par elle-même. Cela n est pas possble dans cet exemple comme l s agt d un couplage entre les servces composés pour synchronser les données relatves aux opératons de cryptage et de décryptage. Alternatvement, s les dfférents fragments du rapport peuvent être décryptés par les servces composés séparément, Assurance peut accéder aux nformatons nécessares lorsqu l route les fragments cryptés vers la Polce. Il est à noter que dans cet exemple la dynamcté n est pas prse en compte car une nteracton drecte entre deux enttés nécesste une synchronsaton avant l échange d nformaton, comme par exemple l échange des clés publques et prvées. En outre, comme coordnateur de la composton, l Assurance ne peut pas extrare des données pour tester les condtons du flux de contrôle. Les standards comme WS-Securty sont essentellement proposés pour supporter les nteractons pont-to-pont et ont un support lmté pour les modaltés de transformaton de cryptologe sophstquées. En conséquence, l est plus smple d utlser les standards pour des nteractons P2P qu ne nécesstent pas un ters. S nous reprenons l exemple rédut, une exécuton centralsée peut supporter les nteractons drectes avec les standards : les transformatons sophstquées ne sont pas requses entre les partcpants et le coordnateur, chaque servce peut fournr chacune de ses sortes en fasant un cryptage séparément. Cet exemple explque l ntérêt de l ntéropérablté fable dans un certan mesure Quels sont les défs et les lmtatons des systèmes décentralsés? Comme explqué dans la secton, un système décentralsé P2P semble plus motvant qu un système totalement centralsé ne l est pas. Pourtant les systèmes décentralsés et surtout les systèmes P2P ont des désavantages qu peuvent les rre lmtés. C-dessous, nous rappelons les plus mportantes lmtatons de l approche P2P, qu ntutvement, sont les avantages des systèmes totalement centralsés. 1. Manque de contrôle : Les systèmes d nformaton vsent à décentralser les fonctonnaltés essentelles des systèmes comme par exemple les nteractons des partcpants, le tratement des requêtes et le routage d nformaton. C est classquement l objectf de l approche P2P où les servces centralsés ne font souvent que satsfare les tâches spécales et pas celles qu sont essentelles. Cet aspect engre une manque de contrôle qu n est pas toujours souhatable. Par exemple, les entreprses qu emploent des systèmes d nformaton ou plus précsément des systèmes de geston de workflow dans le but d automatser leur procédés méters, utlsent ces systèmes pour surveller l état de leur procédés en général. En outre, les nformatons collectées par la survellance des procédés sont utlsées pour fare des analyses à posteror pour amélorer les procédés. Le contrôle et l analyse a posteror caractérsent qualtatvement et quanttatvement l exécuton du système d nformaton, sa stuaton actuelle, pour dédure des conclusons par rapport à un ensemble de crtères d effcacté. Dans une exécuton décentralsée dans laquelle les traces d exécuton sont collectées par des partcpants dfférents, fare une analyse globale et précse n est pas trvale. La noton de manque de contrôle ne dot pas être confondue avec la noton d anonymat. 39

56 Chaptre 3. Etat de l art L anonymat est une foncton qu permet de cacher son dentté dans une communauté. Dans le cadre des applcatons de partage de fchers, l anonymat concerne : l auteur, l édteur, le clent, le serveur, le document partagé et la requête [Gauron2006]. L anonymat est une noton mportante s les fchers soums aux drots d auteur sont partagés d une manère llégale. 2. Instablté : D une manère générale, pour assurer un servce rapde et contnu, un système P2P dot pouvor transmettre des messages en permanence, que ce sot pour envoyer des requêtes, y répondre, en achemner ou fournr un servce d une manère contnue. Tout partcpant dot évdemment rester stable pant ce processus. Le déla de connexon d un nœud dépant drectement du nombre de partcpants vosns avec lesquels l dot garder des nteractons, un degré fable est un avantage pour permettre un fort dynamsme des partcpants. Par alleurs, tout comme pour la durée d une requête, le déla de connexon d un partcpant sera à mettre en rapport avec le temps durant lequel ce partcpant restera connecté au système. Dans les applcatons de partage de fchers, l nstablté d un partcpant n est pas extrêmement mportante comme le même fcher peut être récupéré par un autre partcpant. Mas dans une applcaton d affare où les partcpants ont des relatons contractuelles, l nstablté ne dot pas exster. En conséquence, la nature nstable des réseaux P2P n est pas adaptée aux applcatons méters. Il est à noter que la dynamcté est une caractérstque du nouveau contexte des applcaton dstrbuées comme les servces Web. La dynamcté caractérse plutôt la possblté de pouvor accéder à des nouveaux servces qu devennent dsponbles. Cela ne veut pas dre qu un servce évoqué peut être ndsponble pant son utlsaton contrarement à des applcatons de partage de fchers. 3. Confance : Les applcatons de partage de fchers sont capables de regrouper les partcpants par centres d ntérêts communs créant ans des communautés qu peuvent ellesmêmes s organser. On trouve ce type d organsaton dans les réseaux socaux comme le Facebook. Partager des fchers multmédas ou ben d autre types d nformaton peut engrer des problèmes de confance entre les partcpants qu émettent ou reçovent les nformatons. Une des rasons de problème de confance ou de sécurté en général, est l anonymat qu permet de cacher son dentté. Comme nous l avons soulgné dans les sectons précédentes, l y a pluseurs types d anonymat concernant les enttés mplquées dans une applcaton P2P. Comme les partcpants peuvent cacher leur dentté ans que l dentté des objets partagés, cec peut causer des problèmes de sécurté. Les objets partagés peuvent contenr de l nformaton qu n est pas souhatée par le partcpant émetteur récepteur. Pourtant la noton de confance peut être vue d un autre pont de vue. Cela est explqué dans la secton Intéropérablté Fablté. Les standards de servces Web comme WS-Securty, WS-Trust ou WS-Adressng fournssent dfférent types de support pour établr des nteractons sécursés, chacun en se penchant sur un aspect dfférent de l nteracton en termes de sécurté et de confance Synthèse sur les systèmes décentralsés par-à-par Les systèmes P2P de partage de fchers sont des systèmes vsant à permettre à des utlsateurs la mse en commun d objets et leur recherche en vue de leur récupératon ou de leur utlsaton. Les applcatons P2P de partage de fchers multmédas sont des systèmes à grande échelle qu dovent permettre un nombre d utlsateur varant sur de grands ntervalles. Cette geston peut s effectuer au moyen de serveurs centralsés ou de manère décentralsée. Permettre la concepton et la réalsaton des systèmes P2P demande à répondre à pluseurs questons. Comment les 40

57 3.4. Worflow partcpants sont-ls connectés entre eux? Comment la communcaton est-l étable? Comment sont envoyés les messages et quel type d nformaton contennent-ls? La réalsaton de l approche décentralsée P2P n est pas seulement lmtée aux applcatons de partage de fchers. Du fat de leurs bonnes proprétés des systèmes P2P sont repensés pour être adaptés à toutes sortes de systèmes d nformaton. D alleurs, la thématque de recherche relatve à la geston décentralsée des systèmes d nformaton, comme par exemple les bases de données fédérées [Sheth1991] et les systèmes de geston de workflow [Alonso et al.1997], précède les applcatons de partage de fchers. S les premères applcatons P2P servent prncpalement à la recherche décentralsée de fchers, le champ d applcaton de l approche est ben plus large : la décentralsaton à fable coût peut remplacer des servces centralsés, l échange drecte a pluseurs avantages auss ben socaux ans que technque, par exemple les relatons de confance drectes sont plus smple à établr etc. Quel que sot le système d nformaton, l effcacté fat l objet d un comproms avec la décentralsaton et la centralsaton. Dans un contexte comme le Web où le nombre de servces vrtuellement dsponbles est théorquement llmté, le but d un système d nformaton P2P est d établr des nteractons drectes entre les servces partcpants. C est son prncpal ntérêt. Un effort mportant de nos contrbutons a porté sur la défnton des concepts P2P pour les procédés méters orentés servces. Nous soulgnons que notre compréhenson de l approche P2P est lon des fchers de partage de fchers. Nous cherchons à utlser le paradgmes P2P dans les procédés nter-organsatonnels. Les problèmes appartenant aux dfférents types de systèmes P2P sont dfférents. Par exemple, dans les applcatons de partage de fchers, les problèmes portent sur la réactvté des nœuds, ou encore la rapdté de tratement des requêtes face à la geston de nombreux partcpants alors que le problème essentel des base de données répartes est la cohérence des données dstrbuées. Nous allons vor dans la sute de cette thèse comment l approche P2P a été abordée dans le contexte des procédés nter-organsatonnels. Quels sont les caractérstques et problèmes essentels, lesquels peuvent être combnés, et à quel prx? 3.4 Worflow Cette secton a pour propos la présentaton de l ntatve workflow pour la modélsaton et l exécuton des procédés méters La modélsaton des procédés méters Nous commençons cette secton en fasant une revue de la problématque de la modélsaton des procédés méters en général. L objectf de la modélsaton des procédés méters est de décrre ces procédés à des fns : d évaluaton à pror, de comparason, d automatsaton, d évaluaton à posteror, Conformément à ce qu a été dt précédemment, tout procédé, devant être supporté par un envronnement, commence par la descrpton des procédés méters utlsés. Toute descrpton de procédé applquée à un ensemble d objets (données), tout procédé fat appel à l nterpréteur de procédés qu transforme le procédé en un enchaînement d opératons effectves sur les opérandes. Les opérandes sont (au mons partellement) désgnées par les concepteurs et sont extrates de la base d objets gérée par le système de geston d objet. L exécuton du procédé assure l enchaînement, la coordnaton de ces opératons. En général, un procédé se décompose en sous-procédé. 41

58 Chaptre 3. Etat de l art Chaque sous-procédé peut être consdéré comme une entté qu résout un sous-problème. La résoluton de certans de ces sous-problèmes n est pas automatsé et s exécute dans la tête des agents humans. Une descrpton de procédé dot dstnguer les sous-procédés automatsées de ceux qu ne le sont pas. En général, une descrpton de procédés méters ne détermne pas une et une seule façon d attendre l objectf d un procédé, de résoudre le problème ntal, qu peut d alleurs être lu même redéfn dynamquement. Il appartent alors aux concepteurs de lever l ndétermnsme du procédé en chosssant la ou les prochans sous-procédés à exécuter en s appuyant sur l état d avancement du procédé. Un procédé méter dot permettre de supporter l automatsaton de la producton du produt, et en partculer la coordnaton entre les agents humans et machnes, la mse en évdence des sous tratements, l exécuton de ces tratements et la connassance de l état du développement (jusqu à quel pont l objectf du développement a été attent). La descrpton de ces éléments nécesste l utlsaton des formes concrètes. Les travaux qu sont à l orgne de l ntatve workflow, ont avancé l dée qu un procédé méter peut s exprmer comme un programme nformatque classque. Ils utlsent le vocabulare de programme de procédé. Ces termes sont très controversés parce que l dée d une opératon d exécutant dans la tête de l utlsateur, comme c est le cas de bon nombre d actvtés de traval coopératf, c est à dre non mécanque, non automatque semble en opposton avec l dée de programme, drectement lée à l exécuton par une machne d opératons totalement défnes et le mot programmaton peut alors sembler mal venu. Nous ne voulons pas entrer dans un débat phlosophque. Nous conservons l dée d un procédé méter dot pouvor s exprmer en réutlsant des éléments smlares à ceux utlsés dans des langages de programmaton exstants, mas nous utlsons les termes de descrpton ou modèle de procédés, plutôt que ceux de programme de procédé afn d nsnuer le fat qu une descrpton de procédé ne s exécute pas comme un programme classque. D un pont de vue hstorque, tous les procédés méters créent et transforment des produts en applquant des opératons à des opérandes. On peut donc penser que le beson et donc une certane capacté de descrpton et de coordnaton de ces opératons ne sont pas entèrement nouveaux et que des prédécesseurs aux langages de descrpton de procédés exstent. C est clarement le cas des langages de commandes des systèmes d explotaton qu sont des formes prmtves de langages de programmaton de procédés. Les commandes du système d explotaton consttuent alors les opérateurs élémentares de l envronnement (les types actvtés), les fchers de commandes des opérateurs plus complexes (les types de tâches) et les fchers, gérés par le système de geston de fcher, les opérandes. Le système de geston de fchers joue alors le rôle du système de geston d objets et l nterpréteur de commandes le rôle de l nterpréteur de de procédés. Ans, un fcher de commandes est un procédé méter (de fabrcaton) prmtf et le langage de commandes utlsé pour son écrture un langage prmtf de descrpton de procédés méters. Remarquons également que s un fcher de commandes peut nclure un autre fcher de commande, une tâche peut nclure une sous-tâche, on a une descrpton hérarchque d un procédé. Soulgnons auss que l nterprétaton de ces procédés méters prmtfs gère la coordnaton entre les actvtés purement humanes et les actvtés complètement automatsées. En effet, d une part, l utlsateur utlse les capactés d dentfcaton, de désgnaton ou de sélecton fournes par le langage de commande pour dentfer, partcper ou sélectonner les actvtés ncluses dans le procédé. D autre part, s l utlsateur demande l nterprétaton de fchers de commandes pour réalser des séquences d opératons répéttves, le programme s exécutant peut être nterrompu à dfférents moments pour rre le contrôle du procédé à l utlsateur. L nstant prvlégé de dalogue avec l utlsateur est en général la fn d une opératon. Remarquons auss que les langages de commandes ont été ntroduts pour automatser certanes tâches qu ne l étaent pas auparavant et pour rre cette automatsaton plus flexble. Une autre fablesse de ces langages 42

59 3.4. Worflow est la pauvreté de leurs structures de contrôle, celles-c étant généralement lmtées aux habtuelles tératons et condtonnelles des langages de programmaton classques. Ces structures sont nsuffsantes pour décrre les règles de coordnaton entre sous-procédés d un même procédé [Guabtn and Charoy2004]. Afn d ader au développement des procédés méters à grande échelle, des modèles ntégrant des structures de contrôle plus rches ont été développés, en partculer des modèles dagrammatques. Ces modèles ont été enrchs par des structures décrvant les flux de données et la hérarchsaton des procédés. En général, un procédé y est représenté sous la forme d une boîte, les lens de hérarche entre les procédés sous formes de symboles et de flèches. Mas une fos encore les lmtes de tels formalsmes se sont tradutes par la nécessté de spécalser les nformatons portées sur les dagrammes. Ces nformatons se spécalsent par type de données, par type d applcaton, par type d utlsateur, par famlle... et souvent par combnason de dfférents ponts de vue. Les ponts de vues peuvent être s nombreux qu l est alors nécessare d ajouter des couleurs (pour les dfférents états), des trats de forme dfférentes (pour les dépances de contrôle, donné, transactonnel), des flèches de dfférentes formes, etc. Des exemples de telles représentatons sous forme de dagrammes se trouvent dans de nombreuses spécfcatons, mas de toutes façons les relatons potentelles entre les données du procédés, les acteurs et le contexte sont s nombreuses qu l n y a pas de solutons sans une représentaton nterne et automatsée de ces relatons supportée par des outls capables de recréer les dfférents ponts de vue. Dans tous les cas, la rason de l échec est l absence d un langage opératonnel adapté à la descrpton des procédés ; dans le premer cas, on trouve un langage opératonnel, mas largement ncomplet, dans le second cas ; un langage plus spécalsé, mas mons précs et généralement peu opératonnel. Ans, les développeurs de spécfcaton de procédé ont utlsé les langages de commandes des systèmes d explotatons comme langages prmtfs de programmaton de procédés méters ; mas ceux-c ont montré leur lmtes en ce qu concerne l écrture de procédés de grandes talles et de grande complexté. D autre part, les développeurs de méthodes ont tenté de modélser des procédés plus larges et plus complexes sous forme de dagrammes, mas sans parvenr à décrre de façon suffsamment clare et précse les dfférents aspects d un tel procédé. Par conséquent, la défnton d un langage de descrpton de procédés méter est un problème ouvert. Dans la sute de cette secton, nous allons détaller les éléments caractérstques d un langage de descrpton de procédés. La défnton de ces éléments explque leur consdératon au sen de l ntatve workflow. Il est ensute nécessare de contrôler les appels et l enchaînement des appels à ces opérateurs dans le cadre d une organsaton hérarchque des procédés. Il est clar qu une descrpton de procédés dot posséder au mons les structures de contrôle des langages de commandes ou de programmaton classque. Tout d abord, l est nécessare d ntrodure des structures de contrôle pour modélser l exécuton concurrente des sous-procédés, leur débuts et leur synchronsatons. En partculer, la cohérence des objets manpulés pant l exécuton concurrent dot être satsfate. S certans procédés peuvent se décrre dans un style de programmaton déclaratve, ce n est pas le cas des procédés complètement automatques. Il est clare que c est le cas des procédés les plus créatfs tels que les procédés décrvant les travaux coopératfs comme la concepton coopératve d objets conceptuels. En général, dans ce type de procédé s on est capable de spécfer l objectf du procédé, on n est pas capable de décrre entèrement la façon d attendre cet objectf. On est seulement capable de contrandre l exécuton du procédé en l oblgeant de valder certans ponts de contrôle, même s certans sous-procédés peuvent être complètement spécfés sous une forme algorthmque. Il est à noter qu l est possble de l ntégrer l approche déclaratve dans l approche mpératve dans la modélsaton des procédés. Cec est le cas des procédés flexbles. 43

60 Chaptre 3. Etat de l art dagnostc dagnostc exécuton concepton exécuton concepton confguraton du système (a) 1993 dagnostc confguraton du système (b) 1998 dagnostc exécuton concepton exécuton concepton confguraton du système (c) 2003 confguraton du système (d) 2008 Fg. 3.7 Le cycle de ve d un procédé [van der Aalst2005] De ces observatons, nous pouvons défnr la défnton d un procédé comme sut : Un procédé est un ensemble d actvtés ordonnées selon un ensemble de règles procédurales (mpératf ou déclaratf) pour fare réalser un objectf précs par un groupe d acteurs tels que des machnes et/ou de personnes. Il décrt la structure des acteurs tels que les rôles et les drots, les actvtés de ces acteurs et les crtères de contrôle du déroulement de ces actvtés. L objectf et surtout le cycle de ve d un procédé ne sont pas lmtés à la modélsaton ou à l exécuton des procédés. La fgure 3.7 llustre les étapes d un cycle de procédé d après Van Der Aalst [van der Aalst2005]. Même s cette proposton appartent à l auteur, elle content les étapes essentelles par rapport aux approches de la lttérature. L llustraton nclut le focus des actvtés de recherche qu porte sur les aspects des procédés dans le temps comme la concepton, l exécuton et le dagnostc. Notre traval s ntéresse à la modélsaton (concepton) et l exécuton des procédés L ntatve Workflow Dans la secton précédente, nous avons présenté l évoluton hstorque de la modélsaton des procédés méters. Dans cette secton, nous nous ntéressons à la consdératon de l approche workflow pour ce propos. Un groupe de chercheurs consdèrent un workflow comme une spécfcaton exécutable de procédé. Dans cette approche, les aspects qu ne peuvent pas être spécfés dans une spécfcaton exécutable sont ntégrés dans celle-c avec des spécfcatons déclaratves. Comme nous l avons mentonné c-dessus, cela consttue les workflows flexbles. Une deuxème approche consdère un workflow comme une spécfcaton conforme aux normes défnes par la Workflow Management 44

61 3.4. Worflow Fg. 3.8 Un exemple de workflow en BPMN Coalton [WfMC1996]. Le pont commun de deux approches est une représentaton smlare par une graphe composée des actvtés en forme de boîte et des dépances en forme d arcs. La fgure 3.8 llustre un workflow spécfé en utlsant la notaton Busness Process Modelng Language (BPML) [BPMI.org2001]. Les actvtés du procédé correspondent aux tâches que les acteurs humans ou les machnes dovent réalser. Les losanges caractérsent les dépances du flux de contrôle. Le procédé a un pont de démarrage et un ou pluseurs ponts de termnason. Dans cette notaton, on peut également caractérser les dépances de données des actvtés. Une dépance de données exprme la relaton d entrée/sorte de deux actvtés. Un système de geston de workflow (Workflow Management System, WfMS) est un système nformatque qu transforme la représentaton formelle du workflow spécfé en un format nterne et exécutable dans un envronnement opératonnel. La fonctonnalté essentelle d un workflow est d exécuter le procédé. En outre, l peut avor des fonctonnaltés addtonnelles comme par exemple la vérfcaton du modèle par rapport à un ensemble de crtère de cohérence [Sadq and Orlowska1999] ou la survellance pour fare des analyses a posteror [van der Aalst2005]. Le but ultme d un système de geston de workflow est d éclarer la sémantque d un procédé au sen d une organsaton. Pour ce fare, l approche workflow fat pluseurs hypothèses : Les procédés sont relatvement rgdes et sont adaptés aux expressons en utlsant des notatons smlare aux graphes, La coordnaton des partcpants peut se fare par une entté centralsée (celle qu détent le système de geston de workflow), Ces deux hypothèses sont à l orgne des lmtatons de l approche workflow classque. La premère hypothèse lmte l utlsaton des workflows pour supporter les actvtés qu nécesstent une certane flexblté. L exemple par excellence de ces types de procédés qu ne sont pas ou ben qu sont très dffclement supportés avec des workflow sont les procédés de co-concepton, d édton coopératve ou de co-développement. Cette lmtaton ben connue de l approche workflow[van der Aalst and Berens est à la base des recherches sur les modèles de procédé flexble et sur les systèmes de geston de workflow décentralsés. C est le cœur des travaux lés de nos contrbutons. A l orgne, les systèmes de geston de workflow sont conçus pour supporter des procédés de 45

62 Chaptre 3. Etat de l art producton répéttfs et ne supportent pas le changement des procédés dans le temps. Une telle vson n est pas suffsante dans le contexte des organsatons qu dovent être toujours flexbles et ouvertes aux changements. Un grand nombre de travaux qu portent sur dfférent aspects de la culture de workflow. Compte tenu de la dversté de ces travaux, l n est pas possble de les détaller. Nous fasons une taxonome non-exclusve qu résume les travaux dvers qu portent sur l approche workflow : La geston dynamque des changements du modèle de procédé : Ce groupe de travaux vse à adapter le changement dynamque du modèle de procédé et les nstances actves de celle-c [Rnderle et al.2005] [Ly et al.2008]. Les modèles de workflows flexbles : ceux-c vsent la modélsaton des procédés qu ne peuvent pas être exprmés avec l approche rgde du workflow classque [Deng et al.2006] [Andonoff et al.2005]. La modélsaton transactonnelle : ces travaux ont pour but d ntégrer les proprétés transactonnelles des bases des données à la modélsaton des procédés méters [Hagen and Alonso2000]. Le but de cette approche est de fournr des envronnements robustes comme dans les systèmes de geston de base de données. Le modèle transactonnel peut être ntégré au nveau du modèle de workflow[rusnkewcz and Sheth1995] ou des données gérées pas le workflow[schuldt et al.1999]. Séparatons des préoccupatons : les systèmes de geston de workflow dovent gérer pluseurs dmensons des procédés méters qu ls modélsent. La séparaton des préoccupatons vse à séparer l aspect concerné et le modèle de procédés pour faclter la complexté de la geston. Les exemples ncluent la séparaton des devors [Bertno et al.1999] ou les sphères de comportement [Guabtn et al.2006]. La vérfcaton des modèles de workflow : les travaux de vérfcaton ont pour but de vérfer la cohérence des modèles de procédé comme c est le cas dans les langages de programmaton tradtonnels [Sadq and Orlowska1999]. Il s agt de trouver les deadlocks, les chemns non exécutables et les blockages. Les patrons de workflow : la modélsaton des workflows par patrons faclte leur compréhenson et tratement. Cette approche est smlare à l utlsaton des patrons dans l ngénere des logcels comme les patrons de concepton. Les patrons de workflow ncluent la consdératon des patrons pour abstrare les dépances de contrôle [van der Aalst et al.2000] et les patrons des modaltés de communcaton [Barros et al.2005]. La transformaton des workflows : la transformaton d un modèle fat l analyse du workflow à transformer en vue de le transformer en un autre modèle. Le modèle obtenu peut être équvalent ou pas. Un exemple de la problématque de la transformaton est la producton de modèles de workflow structurés à partr d une spécfcaton aléatore [Kepuszewsk et al.2000] [Lu and Kumar2005] Worklow centralsé versus décentralsé L approche workflow et les outls de geston de workflow, ben qu au cœur des organsatons, souffrent des lmtatons des systèmes centralsés. Les lmtatons précses de l approche centralsée du workflow sont résumées dans les sectons précédentes. La geston de workflow décentralsée est une approche qu n est pas nouvelle mas qu est toujours un sujet d actualté. Elle a pour but de maîtrser les lmtatons de l approche classque du workflow. L dée de base de cette approche qu change de formes dans chaque contrbuton dfférente est de décentralser la modélsaton et l exécuton d un procédé. Ces recherches furent stmulées par le contexte d une course aux systèmes à grande échelle qu s ntensfe pant les années 90 durant lesquelles la popularté 46

63 3.4. Worflow d Internet s accroît. Sans rentrer dans les détalles de la comparason des systèmes centralsés et décentralsés, qu sont largement détallés dans les sectons précédentes, nous fasons une étude des propostons de systèmes de geston de workflow décentralsés. Il est à noter que chaqu un de ces travaux a été ntrodut comme un alternatve aux systèmes centralsés. Certans d entre eux peuvent engrer des composants centralsés, pourtant ls sont confrontés au déf des systèmes de geston de workflow centralsés en général. Exotca/FMQM [Alonso et al.1996] Le système de geston de workflow Exotca/FMQM est développé au centre de recherche de IBM Almaden. Le but de ce projet est d ncorporer la geston des transactons avancées dans un système de geston de workflow dans le cadre des produts d IBM. Le cœur essentel de Exotca/FMQM est FlowMark qu est un produt antéreur d IBM. Avec ce derner, les plate-formes spécales pour l échange de messages et de queng sont utlsées. Le but ultme de Exotca/FMQM est de dmnuer le beson d une entté centralsée qu peut devenr le goulot d étranglement pant l exécuton du procédé. Le focus du système est la dstrbuton du procédé, les aspects lés au passage à l échelle et la tolérance aux pannes. Dans ce système, l entté centralsée qu gère les données du procédé, est décentralsée avec des échanges de messages persstants entre les nœuds. Chaque nœud dspose d un tableau de procédé qu content tout l nformaton statque pour les nstances actves. Pant l exécuton, les nformatons contenues dans le tableau de procédé sont tratées par les processus des actvtés. Les données de procédé sont passés d un output contaner d un nœud vers l nput contaner d un autre nœud récepteur. Le prototype Exotca/FMQM a perms d étuder l mpact de la décentralsaton et la fasablté d une telle approche. Pluseurs aspects ndspensables d un procédé, comme le contrôle du flux d nformaton, qu dovent être étudés dans le contexte de la décentralsaton ne sont pas résolus. ADEPT [Rechert and Dadam1998] Le projet ADEPT (Applcaton Development on Encapsulated pre-modeled Process Templates) concerne le développement d un système de geston de workflow pour l exécuton des procédés nter-organsatonnels à large-échelle. L dée de base d ADEPT est d empêcher la surcharge d un moteur d exécuton centralsé. Afn de dmnuer la surcharge d une entté centralsée, ADEPT transporte les sous-nstance d un procédé sur pluseurs moteur d exécuton en foncton de leur dsponblté. La dsponblté du serveur n est pas la seule crtère pour la sélecton et la mgraton des partes des nstances. La complexté de la spécfcaton du procédé, les dépances entre les nstances partagées sont également consdérées. La sélecton dynamque des moteurs d exécuton rédut consdérablement le temps d exécuton des nstances malgré l augmentaton de la charge lée à la mgraton des nstances. DartFlow [Ca et al.1996] DartFlow est un système de geston de workflow orenté agent. Le système développé à l unversté de Dartmouth, utlse un navgateur Web qu nclut des applets Java pour les utlsateurs fnaux du système. L utlsaton des concepts agents font le système hautement flexble lorsque l utlsaton des applets le font fable et ndépant des plate-formes. La motvaton de DartFlow, qu date ben avant des technologes de servces Web, est de maîtrser les dffcultés nhérentes des systèmes de geston de workflow centralsés. Plus précsément, chaque nstance de workflow est modélsée comme un agent moble qu porte les données nécessare pour son exécuton. L agent qu concrétse l nstance est transporté d un nœud à un autre en foncton de l état de l nstance. Il est à noter quelle transport de l agent peut être fat par les nœud ans que l agent lu-même. En conséquence, l agent content des nformatons addtonnelles aux données de l nstance de procédé. Une entté centralsée n est pas exgée pour 47

64 Chaptre 3. Etat de l art l exécuton d une nstance. METUflow [Gokkoca et al.1997] METUFlow est un système de geston de workflow développé à L Unversté de Mddle East Techncal. Le but de ce projet est de fournr un système de geston de workflow décentralsé dans lequel une nstance d un procédé est exécutée par un ensemble de nœuds dstrbués dans un réseau. Chaque nœud exécute une parte de l nstance qu l reçot. Ans, l exécuton est dstrbuée. Cela augmente la tolérance aux pannes de l exécuton de l nstance du procédé. L approche du METUflow est basée sur l observaton de l exécuton des nstances en traçant les événements produts par ces derners. En conséquence, chaque nœud dot décder quand l dot exécuter une actvté qu appartent à son nstance. L actvaton, la fn ou l échec des actvtés génèrent des événements à propager vers les nœud correspondants. L occurrence d un événement est possble s ses gardes sont satsfates. Les défntons des événements et leur gardes sont smlares au tratement complexe des événement (Complexe Event Processng) [Ad and Etzon2004]. Au nveau de l mplémentaton, chaque nœud est un objet CORBA avec une nterface qu nclut les nteractons correspondantes. SELF-SERV [Benatallah et al.2002] SELF-SERV est un des premers exemples de système de geston de workflow décentralsés vsant les archtectures orentées servces. Il a été développé à l Unverste de New South Wales avant les efforts de standardsaton des procédés composants les servces Web. Comme de nombreux systèmes exstants, le but de SELF-SERV est de dmnuer le rôle d une entté centralsée dans la composton dynamque d un ensemble de servces. La composton d un servce Web est exprmée comme une machne à états. Des mécansmes basées sur les crtères de dsponbltés sont proposées pour le transfert de contrôle d un nœud à un autre. OSIRIS [Schuler et al.2004] Ce système récent est proposé à ETH Zurch. Le but de OSI- RIS est étuder la décentralsaton des procédés méters. Le système est composé de composant centralsés ans que d agents mplémentés sur des nœuds décentralsés. Les composants centralsés assurent les servces d annuare, le support transactonnel, et les servces qu ne peuvent pas être fourns d une manère décentralsée. Les composants centralsés sont réplqués pour augmenter la tolérance aux pannes et la dsponblté. L exécuton décentralsée est fate entre les nœuds en coordnaton avec les composants centralsés. La cohérence et la synchronsaton des composants réplqués ne sont pas explctement défnes. Le projet a pour but de dmnuer la surcharge d un composant centralsé pant l exécuton d un procédé en routant les nstances vers les nœuds plus dsponbles. PeCo [Coon2002] Peco qu est l abrévaton de Peer Collaboraton. C est un projet réalsé au sen de l organsaton Proteus Technologes. Le but de cette organsaton est de fournr des plate-formes de coopératon pour les domanes des servces d ntellgence, de transportaton et le secteur médcal. Plus précsément, la plate-forme Peco est un système de geston de workflow réalsé selon une approche P2P. Dans la plate-forme, les agents sont responsables pour l exécuton de certanes tâches comme la coordnaton d un group d agents, les servces de base, le déploement des tâches ou l admnstraton. L nfrastructure Jn est utlsée pour supporter la découverte, la tolérance aux pannes et la conscence de dsponblté des agents mplqués. En général, les agents contactent le coordnateur d un groupe pour coopérer avec les autres agents. 48

65 3.4. Worflow WWPD et WWP [Fakas and Karakostas2004] Ce système de workflow décentralsé est composé essentellement de deux composants WWPD (Web Workflow Peers Drectory) et WWP (Web Workflow Peer). Il a été proposé par les checheurs de l Unversté de Metropoltan de Manchester. Le WWPD est un composant centralsé qu fournt le servce d annuare. Les agents qu mplémente le composant WWP sont enregstrés au près de WWPD pour utlser les servces des autres agents et fournr leurs servces à la communauté. Pant l exécuton des nstances de workflow, un système de notfcaton est utlsé pour coordonner les agents mplqués dans une nstance de workflow. L archtecture décentralsée du workflow a pour objectf de dmnuer la charge d un composant centralsé en décentralsant la coordnaton. RanMan [Paul et al.1997] RanMan est un système de geston de worfklow décentralsé. C est un système orenté-objet développé au sen de IBM. Ranman est conçu pour fonctonner sur l Internet afn d exploter l ntéropératblté des composants accessble sur l Internet. C est un système composé des agents fablement couplés. Le système RanMan est basé sur l API Ranmaker qu fournt une squelette pour la concepton et l exécuton des workflow. Ranmaker dentfe quatre abstractons mportantes pour le domane workflow : Sources, Actvtés, Acteurs, et Tâches. Dans ce système, la geston du procédé, la dstrbuton des actvtés, le servce d annuare, et la lste des tâches actves sont tratés par des composants ndépants qu fournssent le servce de workflow aux utlsateurs de l Internet. Outre les éléments de base d un système de geston procédé, des fonctonnaltés addtonnelles comme l analyse de performance, la geston des exceptons, et les aspects de sécurté sont étudées dans le cadre du système RanMan. Apparue avec l Internet, RanMan est un des premers systèmes de geston de workflow fonctonnant sur l Internet. Serpty [Grundy and Hoskng1998] Serpty est un envronnement de geston décentralsée développé à l Unversté de Wakato et l Unversté de Auckland. Le but de l envronnement est de fournr un support pour la concepton et l exécuton coopératve des projets de développement logcel. Afn de fournr un support robuste, effcace et décentralsé, l envronnement Serpty est basée sur une archtecture décentralsée qu utlse les communcatons multcasts pont à pont. Chaque utlsateur de l envronnement dot dsposer de ses propres composants qu dovent lu permettre de communquer avec les autres utlsateurs de l envronnement. En employant les composants de la plate-forme, les utlsateurs peuvent édter les spécfcatons des procédés. Afn d exécuter le procédé, chaque utlsateur a un envronnement d exécuton de procédé capable d exécuter les actvtés locales. L exécuton est condute par la geston complexe des événements qu sont propagés vers les utlsateurs par ceux qu les produsent. Outre les éléments caractérstques d un envronnement de geston de procédés, des fonctonnaltés comme la trace de l exécuton et des outls de conscence de groupe sont fourns. Matrx [SDSC1999] Le projet matrx est développé au sen des laboratores de San Dego Supercomputer Center. Le projet Matrx porte sur la recherche et le développement des plateformes des protocols de workflow conçus pour le grde. Les workflow grds sont utlsé pour le tratement des procédés orentés donnée. Ces derners concernent la manpulaton des données de grande quantté venant par exemple des satelltes artfcelles. Actuellement, le mddleware Matrx fournr un support pour que les servces Web pussent être ntégrés dans le grde de Matrx. Les fonctonnaltés de notfcaton et de requête sont offertes d une manère dynamque pour coordonner les partcpants de grde. Outre les servces caractérstques d un workflow et d une plate-forme de grde, un servce de brokerng est fourn pour des analyses de performance. 49

66 Chaptre 3. Etat de l art Les protocoles pour la coordnaton et la confluence des brokers sont conçus. Mentor [Wodtke et al.1997] Ce système de geston de workflow est peut être le plus proche au modèle proposé dans cette thèse. Il consste en l étude de la décentralsaton du pont de vue de la producton de fragments de worfklow coopérants. Le système proposé consdère également des composant centralsés pour satsfare certanes fonctonnaltés telles que la synchronsaton des branches concurrentes. Le modèle de procédé est basé sur une descrpton UML composée de deux partes ndépantes, notamment le flux de données et le flux d actvté. La consdératon des composants centralsés tels que TP, est évdemment la lmtaton de cette approche. Toutefos, la relaton entre le flux de contrôle et le flux de donnée n est pas tratée du pont de vue de l mplémentaton des systèmes de geston de workflow. Néanmons, nous avons utlsé une approche smlare à celle de MENTOR pour prouver l exacttude des algorthmes que nous avons employés. Une analyse comparatve des solutons de workflow décentralsé c-dessus est présentée dans le tableau 3.1 à la fn de ce chaptre Autres travaux lées Depus 2004 l y a un certan nombre de travaux ndépants qu sont vrament proches à notre approche. Dans [Nanda et al.2004], la traducton d une spécfcaton centralsée BPEL en un ensemble de procédés coopérants et dstrbués est étudée. Dans [Chafle et al.2005] [Nanda and Karnk2004] [Chafle et al.2004], le même traval est étu pour dscuter dfférents aspect de décentralsaton comme les problèmes de synchronsaton dans le cas de l exécuton décentralsée, ou ben l mplémentaton des restrctons de flux de données entre les fragments traduts. Le traval orgnal est basé sur le partton d un code mpératf en analysant le flux de contrôle et de données. La contrbuton essentelle vse à dmnuer les communcatons entre les fragments décentralsés en gardant une analoge avec les problèmes de partton d un code tout en utlsant les méthodes smlares. Même s ce traval consttue une avancée mportante dans le domane, l présente de nombreuses lacunes. Comme la fondaton essentelle est motvé par le code mpératf, les aspects du workflow dont les compostons sont basées ne sont pas tratés. Les exemples ncluent l élmnaton des chemns morts (Dead Path Elmnaton) [Leymann and Roller2000], les patrons de workflow et les compostons conversatonnelles. En se basant sur les mêmes prncpes, [Sadq et al.2006] étude la traducton du contrôle de flux d une spécfcaton workflow mas ne se penche jamas sur les mêmes problèmes. [Bares et al.2007] utlse une technque de translaton des procédés BPEL en utlsant les technques développées dans la réécrture de graphes. Il s agt de la réécrture du flux de contrôle dans un contexte moble. Un autre traval qu précède tous les travaux c-dessus est présenté dans [Atlur et al.2001]. Le problème de décentralsaton est étudé dans un contexte de sécurté. Même s les contrbutons précédent l approche servce et sont largement ntutves, le traval est très nnovateur. Les hypothèses de ce traval restent rréalstes dans le contexte servce. Parce que l opératon de translaton assume la présence d un mécansme mplémenté par les partcpants de workflow. Comme nous avons déjà soulgné, cette hypothèse est forte dans le contexte des archtectures orentées servces et condut à une soluton ntutve. La dfférence de ces travaux, par rapport aux travaux antéreurs qu portent sur la geston décentralsée, est qu ls attaquent le problème de la geston décentralsée comme un problème de traducton de spécfcaton et pas une queston de support archtectural. 50

67 3.5. Synthèse et stuaton par rapport à d autres approches de la problématque Synthèse sur le workflow décentralsé Dans cette secton, nous fasons une synthèse sur les travaux lées concernant les systèmes de geston de procédés. Nous complétons cette secton avec un tableau qu synthétse en montrant les ponts fables forts et les ponts fables de chacune des propostons essentelles. Depus les années 1990, l évoluton de l nformatque et les technologes de communcaton suvent des voes qu font des workflows l un des outls essentels pour la concepton et l mplémentaton des procédés méters ntra et nter-organsatonnels. La mse en œuvre des aspects essentels des procédés méters comme la modélsaton, l automatsaton, l exécuton, et le survellance trouvent dans les workflows l approche qu semble parfatement adapté. Ce mouvement s est structuré dans le contexte des procédés méters pus dans le contexte des archtectures orentées servces. Une génératon de contrbutons ayant débuté au début de ces années, nommés système de geston de workflow décentralsés, sont en mesure de partcper plenement à la défnton de nouveaux objectfs. Les succès et les premères retombées mplquent même une réflexon sur le renouvellement des approches. Ce renouvellement, toujours dffcle, est faclté par le fat que les ancens sont encore relatvement jeunes. Dans ce jeu subtl, un système de geston de workflow décentralsé dot ntégrer des aspects complémentares : ceux de l nfrastructure de communcaton sous-jacente et les aspects applcatfs de la geston décentralsée. L approche workflow décentralsé maîtrse les lmtatons essentelles de l approche classque du workflow centralsé comme elle permet essentellement de confgurer les nteractons des partcpants par rapport à un ensemble de crtères. Le problème essentel des systèmes de geston de workflow décentralsés est qu ls ne sont pas adaptés aux nouvelles exgences des archtectures orentées servces parce qu ls se basent sur des hypothèse qu peuvent être rréalste dans ce nouveau contexte. Un autre ensemble de travaux portent sur la producton de fragments de procédés coopérants à partr d une spécfcaton centralsée smlare aux contrbutons de notre thèse. Essentellement, ls proposent des structures de données et des algorthmes qu concrétsent l opératon de transformaton. Formulaton élégante, postve, mas qu pourrat paraître un peu ambguë. À vra dre, les propostons actuelles portant sur la partton des spécfcaton semblent beaucoup plus se préoccuper de l opératon de partton et tentent de l adapter sans fournr une soluton complète et extensble aux exgences dverses. Par exemple, [Nanda et al.2004] se penche sur la dstrbuton des actvtés d ntalsaton des varables dans des fragments de procédés coopérants lorsque [Bares et al.2007] se penche sur la décentralsaton du flux de contrôle. L exécuton décentralsée des procédés avec des fragments dérvés d une spécfcaton centralsée est une approche très nouvelle qu touche des domanes de plus en plus larges. Les ponts forts de cette approche tels qu ls sont défns dans les travaux lés sont nombreux. Alors que la standardsaton et la geston des procédés par l approche workflow ont tance à converger, celle-c est une approche prometteuse. 3.5 Synthèse et stuaton par rapport à d autres approches de la problématque Dans cette secton nous fasons une synthèse du contexte et des travaux relatfs. Il s agt d une méta-synthèse des synthèses antéreures. Au cours de ces 20 dernères années qu ont vu les Scences et technologes de l nformaton et de la communcaton (STIC) révolutonner la socété, l évoluton des composants, des langages et des nfrastructures de réseau engagent nformatque et télécommuncatons dans une convergence 51

68 Chaptre 3. Etat de l art ADEPT [Rechert and Dadam1998] Exotca/FMQM [Alonso et al.1996] SELF-SERV [Benatallah et al.2002] OSIRIS [Schuler et al.2004] WWPD [Fakas and Karakostas2004] PeCo [Coon2002] METUFlow [Gokkoca et al.1997] MENTOR [Wodtke et al.1997] Matrx [SDSC1999] Serpty [Grundy and Hoskng1998] RanMan [Paul et al.1997] Archtecture sophstquée Protocoles sophstqués P2P Mgraton Confguraton avancées des nteractons P2P Tab. 3.1 L analyse comparatve de workflows décentralsés 52

69 3.5. Synthèse et stuaton par rapport à d autres approches de la problématque qu ne relève plus d une mse en commun d éléments ou de potentels mas touche chacun des deux domanes au cœur de sa logque de constructon et de fonctonnement des entreprses vrtuelles. Les conséquences organsatonnelles de cette mutaton, qu elles concernent les organsatons ou les nsttutons publques, ne sont cepant guère prses en compte. Non par aveuglement mas parce que les trajectores de reconfguraton restent dffcles à prévor. Évoluton de la demande des consommateurs, restructuraton des organsatons, modaltés et pérmètre de l nterventon publque : de nombreux éléments sont très ncertans, ne permettent pas d établr des stratéges opératonnelles à long terme. Car s la convergence semble néluctable, l reste à en précser le rythme et les modaltés. S les problèmes actuels des systèmes d nformaton et de l entreprse vrtuelle sont en général très dvers, ls sont auss très nombreux. Après une longue phase de recherche dversfée à la mesure du fosonnement actuel du domane, les efforts de standardsaton ont perms l émergence des servces Web comme support concret de développement des applcatons accessbles par l Internet. Dscplne jeune, basée sur les efforts antéreurs de l ndustre, les archtectures orentées servces ont trouvé au sen des procédés méters le champon qu a su les acclmater aux problématques de la recherche. Dans un contexte organsatonnel certes toujours complexe mas récemment stablsé, les archtectures orentées servces sont en mesure d établr leur propre stratége de concepton et d mplémentaton. Alors qu auparavant l ndustre semblat construre des paradgmes d archtectures orentées servces en foncton de leur besons, c est mantenant les archtectures orentées servces qu détermnent les éléments majeurs de leur problématque. Par archtecture, l ne faut pas entre des mplémentatons ou de technologe pures mas l affrmaton d une culture servce structurée orgnellement autour des notons d autonome, de couplage fable, de dynamsme et de nombreuses autres. Certes, durant les développements des concepts et des technologes des servces Web, l entreprse vrtuelle qu les emploent dut affronter les lmtatons des envronnements d exécuton centralsés. L ntroducton de nombreuses applcatons de partage de fchers multmédas P2P attre l attenton des acteurs de la communauté de procédés méters. Les avantages des conceptons et les archtectures P2P explquent pourquo les scentfques et les ndustrels voent en ce modèle une vértable alternatve aux réalsatons actuelles. Même s de bonnes proprétés motvent l utlsaton des systèmes P2P au sen de l entreprses vrtuelles, à cause de leurs lmtatons, les organsatons sont lons de les consdérer comme un sanctuare pour mplémenter leur procédés méters. Comme nous avons détallé dans ce chaptre, les efforts de standardsatons consdèrent l utlsaton de l approche workflow pour la concepton et l mplémentaton des archtectures orentées servces qu vsent la composton. L émergence de l approche workflow dans l entreprse vrtuelle est restée un phénomène relatvement dscret au cours des années Dans les années qu suvent, l évoluton de l approche workflow sut des voes qu font de la décentralsaton l un des aspects essentels pour son développement. Ces travaux qu précédent la vson servce, sont motvés par l évoluton du support réseau, l espor mmense suscté par le potentel llmté de la décentralsaton qu ncte en effet à leur utlsaton. La motvaton essentelle des travaux qu portent sur l exécuton décentralsée de workflow porte sur la répartton des moyens dans un système dstrbué comme par exemple le déploement des nstances vers des machnes plus dsponbles. Cela consttue, l est vra, un déf mportant en termes de complexté dans un domane nouveau. Pourtant elle ne pr pas un essor nouveau dans le contexte des archtectures orentées servce. Il est clar que les envronnements de geston de procédé décentralsés actuels ne remplssent pas les nouvelles exgences de l approche servce. Certans d entre eux ne sont que des applcatons légères qu mplémentent les protocoles de communcaton auprès des partcpants mas ne fournssent qu un support très relatf aux nouvelles exgences des systèmes structurés autour des archtectures orentées servces comme par exemple l autonome. Parce 53

70 Chaptre 3. Etat de l art que tout smplement les organsatons qu sont accessbles en tant que servces ne peuvent pas avor l ntenton d mplémenter les protocoles ou les applcatons exgés par l envronnement de décentralsaton. De ces observatons, on peut retrer deux conclusons essentelles. La premère lmtaton est que les systèmes de geston de workflow ne consdèrent pas les crtères dvers qu peuvent exster dans un procédé nter-organsatonnel et se penchent seulement sur les avantages lés à la performance de la décentralsaton. La deuxème est leur problème d adéquaton aux archtectures orentées servces. Intutvement, les protocoles ou les scrpts qu ls exgent peuvent être contradctores avec l autonome des servces qu sont censés être dynamques et ouverts à l évoluton nterne. Quo qu l en sot, l utlsaton des systèmes de geston de workflow décentralsés devent de plus en plus acceptable. De l autre côté, les efforts de standardsaton ont perms l émergence de pluseurs aspects nouveaux qu n étaent pas présents dans le contexte de l entreprse vrtuelle. Un de ces aspects est la moblté des spécfcatons basées sur XML entre les organsatons et même les outls. Par exemple, un procédé spécfé ou nstancé en WS-BPEL par une organsaton peut être faclement reçu et exécuté par une autre organsaton. Cet envronnement d exécuton pour le procédé reçu est très rasonnable pusque ce derner est une spécfcaton standardsée. La moblté des spécfcatons commence à attrer l attenton des chercheurs de communautés dverses. Mas aucune contrbuton n est étable. Chaque contrbuton se penche sur un aspect ndépant de la moblté ou de la décentralsaton sans se focalser sur les motvatons et les défs sous-jacents. On peut également ajouter la réalsaton concrète de la moblté des spécfcatons aux manques soulgnés c-dessus. Nous pouvons résumer la synthèse des travaux lés et l analyse que nous avons fat en quelques lgnes comme sut : Une nouvelle forme de concepton et d mplémentaton des procédés méters structurée autour des servces s nstalle dans la communauté auss ben scentfque qu ndustrelle. Certes, cette nouvelle approche a pluseurs avantages. L exécuton décentralsée des procédés méters est étudée largement dans les travaux qu précédent l approche servce mas les contrbutons ne sont pas en adéquaton avec les nouvelles exgences de cette dernère. Les apports secondares de la standardsaton ont des relatons orthogonales avec les exgences des procédés méters en termes de décentralsaton. Ces relatons ne sont pas clares et sont peu étudées dans la lttérature. 54

71 Chaptre 4 La modélsaton d un procédé et sa décentralsaton par défaut Sommare 4.1 Introducton Le modèle du procédé Éléments caractérstques du modèle proposé et hypothèses prélmnares Exemple llustratf Défnton formelle Prncpes de décentralsaton et l orgnalté de l approche La décentralsaton d un procédé centralsé Les algorthmes pour la producton des fragments coopérants Vue d ensemble et présentaton ntutve des algorthmes Notatons Interconnexon avec les actvtés de postset et de postset étue Interconnexon avec les actvtés de preset et de preset étue Synthèse Introducton Dans ce chaptre, nous présentons notre premère contrbuton qu concerne la défnton d un procédé méter qu caractérse la composton d un ensemble de servces. Ce premer pont est essentel pour aborder de façon cohérente et réalste l exécuton décentralsée d une composton. Par la sute, nous présentons notre technque qu décentralse un procédé sans se baser sur un crtère précs de concepton comme peuvent l être les poltques de flux d nformaton. Le chox d un modèle de spécfcaton semble fare parte des problèmes sujets à polémques, tant l est ntmement lé à la culture scentfque des concepteurs de procédé, au domane d applcaton, et auss aux mplémentatons vsées. Le modèle présenté dans ce chaptre est un modèle théorque qu a pour avantage d être smple et précs. Mas dans le chaptre sur l mplémentaton, nous justfons la mse en œuvre avec un langage de spécfcaton concret comme WS-BPEL. Par la sute de ce chaptre, nous allons utlser l exemple de procédé llustré dans la sous-secton Cet exemple est une verson étue de l exemple de motvaton que nous avons utlsé dans le chaptre de problématque. S l exemple est smple, nous attrons l attenton sur le fat qu l est 55

72 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut suffsamment général pour exprmer les dfférents types de concepts qu nous ntéressent. Les algorthmes sont d abord décrts d une manère abstrate et pus llustrés par des exemples. 4.2 Le modèle du procédé La modélsaton des procédés n est pas nouvelle, pusque l on s y ntéresse depus de nombreuses années, d abord des procédés ndustrels très automatsés, pus des procédés plus créatfs mplquant des nteractons de personnes à personnes, comme les procédés logcels [Godart1993]. Comme le montre ben l étude bblographque, l n exste pas une soluton unverselle aux problèmes que posent la spécfcaton d un procédé qu compose un ensemble de servces. Tout au plus, une proposton peut cbler au meux une classe de problèmes à résoudre. Nous pensons que plutôt que de défnr un langage, l s agt de réutlser des formalsmes exstants. Le formalsme que nous utlsons est composé des concepts empruntés à des domanes varés : workflow [Leymann and Roller2000], théore des graphes [Bondy and Murty1976], systèmes d nformaton [Fscher2007]... Il crconscrt le type de concepts que l on veut exprmer et le type de problèmes que l on peut espérer résoudre Éléments caractérstques du modèle proposé et hypothèses prélmnares Un procédé méter est la producton d un objet ou la réalsaton d une tâche. Le modèle d un procédé méter décrt un moyen systématque pour produre un objet ou réalser une tâche d un certan type, d une certane classe. Une étude rapde des langages de programmaton met en évdence dfférents paradgmes de modélsaton des procédés (procédurale, logque, objet, fonctonnelle, mpératve, déclaratve, séquentelle, parallèle...). Chaque style de programmaton semble meux correspondre à certans domanes d applcaton que d autres [Osterwel1997]. Cec est valable pour la spécfcaton des procédés. Comme détallé dans l état de l art, un modèle de procédé exécutable motve plus son utlsaton qu un modèle déclaratf ou partellement exécutable ne l est pas. Cette motvaton condura à une melleure spécfcaton de composton et en conséquence à une melleur exécuton et geston. Comme nous l avons déjà soulgné, un procédé méter qu spécfe la composton d un ensemble de servce consste essentellement à défnr la relaton d ordre qu dot être mantenue entre les nvocatons des servces composés [Weerawarana et al.2005]. Il s agt du flux de contrôle du procédé. Un modèle de procédé défnt également les dépances de données entre les dfférents nvocatons. Ce derner consttue le flux de donnée du procédé [Leymann and Roller2000]. La structure du flux de contrôle peut engrer dfférent types de dépances de contrôle entre les éléments du procédé. Ces dépances peuvent être exprmées par des patrons de contrôle (AND-jon, AND-splt, OR-jon...) d une manère abstrate. Il n exste pas actuellement de consensus sur la façon de représenter le flux de données ou d autres types de flux comme le flux transactonnel [Hagen and Alonso2000]. Dans la modélsaton des procédés, nous étudons tros ponts prncpaux. Le premer pont concerne le flux de contrôle du procédé. Le deuxème est une généralsaton des dépances de données. Fnalement, le trosème pont concerne les aspects conversatonnels des servces composés. Hypothèses concernant le modèle proposé : S certans procédés peuvent se décrre dans un style de programmaton mpératve comme des workflows, les descrptons arbtrares peuvent être dffcles à analyser et à manpuler [Ouyang et al.2006]. Pourtant, l est souvent possble de passer d un modèle arbtrare à un modèle équvalent plus structuré toute en gardant la sémantque. Le concept de procédé structuré est proposé dans [Kepuszewsk et al.2000]. On appelle un procédé structuré, une spécfcaton de procédé qu est restrente par un certan nombre de 56

73 Lemma 1: Every splt control element must have at least one correspondng jon control element. Lemma 2: In general (unstructured) workflows, the splt and jon control elements need not be of the same type Lemma 3: A splt control element may have multple unque correspondng jon control elements. Lemma 4: A jon control element may correspond to more than one splt control elements Le modèle du procédé A1 C1S or A2 A1 C1S or A2 A1 C1S or A2 C2S or C3S or or C2S C3S or or C2S C3S or A3 C2J or A7 A4 C1J A5 or A6 C3J or A8 A3 C2J or A4 A6 or A5 A6 C1J A7 C3J or A8 A3 C2J or A7 A4 A5 A6 A6 A7 C1J or C3J or A8 (a) Workflow wf1 (b) Workflow wf2 (c) Workflow wf3 Fg. 4.1 La transformaton Fg. 4. Steps d un n mappng modèle an unstructured de procédé workflow arbtrare wf1 nto a en structured un modèle wf3 structuré en deux étapes [Lu and Kumar2005] Defnton 4 (Msmatched par). A par of correspondng control elements (s, j) s msmatched f s s a splt-choce and j s a jon-parallel element, or s s a splt-parallel and j s a jon-choce element. (s, j) s called a msmatched par. Defnton 5 (Improper nestng). A par of matchng control elements (s, j) s mproperly nested wth another par of matchng control elements (u, v), f s (or j) s n a path from u to v, but j (or s) s not n ths path. Ths s denoted as (u, v) [ ] (s, j). Defnton 6 (Order of Improper nestng). (u, v) [ ] (s, j) s called frst-order mproper nestng, f there s no (x, y), such that (u, v) [ ] (x, y), where (x, y) (s, j). (u, v) [ ] (s, j) s called nth-order mproper nestng f there exst (u, v) [ ] (x, y ), where (x, y ) (s, j) and =1, 2,, n-1. We use (u, v) [ ] {(x 1, y 1 ), (x 2, y 2 ),, (x n, y n )} to denote n pars of correspondng elements nested nto (u, v). Fg. 5 shows two examples of mproper nestng. In both examples, a par of correspondng control elements (C2S, C2J) s nested wth another par of correspondng control elements (C1S, C1J), constructng a frst-order mproper nestng (C1S, C1J) [ ] (C2S, C2J). In ths fgure, A, B, C, D represent any actvtes or contrantes syntaxques au nveau du flux de contrôle. Dans un procédé structuré, à chaque élément de dsjoncton (AND-splt, OR-splt...) dot correspondre un élément de joncton de même type (AND-jon, OR-jon...). Ans, un procédé structuré peut être construt d une manère récursve en mbrquant les fragments par des pares approprés. Le fgure llustre un exemple d un procédé arbtrare et sa transformaton en un procédé structuré équvalent en utlsant les technques présentées dans [Lu and Kumar2005]. Il est clar que nous avons dû fare cette hypothèse smplfcatrce pour nous concentrer plus sur les dffcultés de notre approche. Nous pourrons travaller avec des procédés arbtrares mas au coût de fare des analyses extrêmement sophstquées. Nous pouvons constater que cette dffculté peut être lmtée en assumant que les procédés arbtrares sont transformés en leur équvalent structuré dans un étape qu précède la décentralsaton. En vue de la quantté des travaux et des outls portant sur les opératons de transformaton [Lu and Kumar2005] [Sadq and Orlowska2000b] [Sadq and Orlowska2000a], cette hypothèse semble rasonnable. Plus formellement, cette hypothèse est exprmée par Hypothèse 1.1. Hypothèse 1 (Procédé Structuré) Un procédé, P, qu spécfe une composton de servces est un procédé structuré. Un des problèmes des procédés est la geston de la concurrence entre ses actvtés [Schuldt et al.1999]. La concurrence concerne la manpulaton des varables globales du procédé par des actvtés exécutées en parallèles. Alors que la concurrence est consdérée comme une stuaton problématque qu r l exécuton dffcle, certans technques nouvelles ont prouvé leur ntérêt dans la phase d exécuton [Guabtn et al.2006]. Comme nous nous ntéressons aux échanges drects entre des servces composés au sen d un procédé, la concurrence n est pas un aspect souhaté de notre mode d exécuton où l ne peut pas avor des données partagées. En conséquence, nous assumons que la concurrence n exste pas dans les modèles de procédé que nous consdérons. Il est à noter que la concurrence peut être détectée pant les phases de concepton du procédé en employant les dfférentes technques comme [Marjanovc2000]. Nous pouvons concrétser cette hypothèse par Hypothèse

74 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Hypothèse 2 (Concurrence) Un procédé, P, qu spécfe la composton de servces ne content pas des actvtés concurrentes qu peuvent accéder aux mêmes données de procédé en même temps. La présence de l hypothèse 1.2 est équvalente à l hypothèse suvante (Hypothèse 1.3). Car, dans une modélsaton abstrate la présence de la concurrence est caractérsée par l échange de données entre les actvtés qu ne sont pas sur le même chemn. Hypothèse 3 (Flux de contrôle) Un procédé, P, qu spécfe la composton de servces ne content que des dépances de données entre les actvtés qu sont sur le même chemn de contrôle. Nous avons fat également des hypothèses concernant la modalté de communcaton entre les servces qu exécuteront les procédés. Nous détallons ces hypothèses au long de ce chaptre Exemple llustratf d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg. 4.2 Un exemple de procédé Dans cette sous-secton nous présentons un procédé qu compose un certan nombre de servce. Dans le reste de ce chaptre, nous allons l utlser comme exemple de motvaton. Son objectf est d llustrer smplement le fat que les dépances de contrôle et de donnés peuvent co-exster sous dfférentes formes. A ce nveau, nous préférons utlser cet exemple abstrat au leu d un procédé réel en vue de faclter les notatons, parce qu l est plus smple d llustrer des aspects conversatonnels sur le même exemple en changeant la confguraton de ce derner. Le procédé content 21 actvtés : a 0, a 1,..., a 20. Les actvtés sont lées les unes les autres par les dépances de contrôle et de donnée. Les dépances de contrôle caractérsent l ordre 58

75 4.2. Le modèle du procédé partel d exécuton des actvtés. Les dépances de données caractérsent les relatons entre les entrées et les sortes des actvtés du procédé. Les dépances de donnée sont : d 0,..., d 6. Les dfférentes condtons de transton lées à la combnason des dépances de contrôle sont représentées par deux types de patrons : AND-splt/AND-jon et OR-splt/OR-jon. Le patron AND-splt défnt un pont de procédé où le flux de contrôle se dvse en pluseurs flux de contrôle en parallèle, permettant une exécuton concurrente. Respectvement, le patron AND-jon défnt un pont de procédé où pluseurs flux de contrôle concurrents convergent et se synchronsent en un seul flux de contrôle. Le patron OR-splt défnt un pont de procédé où, selon des condtons de transton, un sous ensemble de flux de contrôle est actvé. Respectvement, le patron OR-jon défnt un pont de procédé où un sous ensemble du flux de contrôle convergent et se synchronsent, s ls sont déjà actvés. Une queston naturelle se pose : les actvtés correspondent à quo? Conformément à ce qu a été dt dans les sectons précédentes, les actvtés d un procédé qu composent un certan nombre de servces sont essentellement des nvocatons des opératons qu appartennent aux servces. L nvocaton d un servce peut se fare avec des nteractons un ou b-drectonnelles. Une nteracton un-drectonnelle peut évoquer un servce ou ben recevor une nvocaton. Une nteracton b-drectonnelle fat une nvocaton à un servce externe et att en retour une nvocaton de la part du derner. On peut la consdérer comme deux nteractons un-drectonnelles consécutves. Il est à noter que pour tester les condtons de transtons pour un OR-splt, un certan nombre de varables de procédé peuvent être testées. Pour ce fare, les actvtés locales dovent être exécutées. Les actvtés locales d un procédé ne font pas appel aux servces externes. Chaque actvté peut avor un certan nombre d entrées ans que de sortes. Les actvtés locales ont seulement des entrées comme elle ne fournssent ren. Les actvtés un-drectonnelles peuvent avor des données de sorts s elles nvoquent des servces externes ou ben elles peuvent avor des entrées s elles reçovent des nvocatons venant des servces externes. Un procédé a une unque actvté de start et une unque actvté fnale Défnton formelle Après une étude générale des procédés qu caractérsent le modèle consdéré, nous donnons une présentaton formelle de ce derner. Défnton 4 (Procédé) Un procédé, P, est un tuple (A, D, E c, E d, S ) où : 1. A est un ensemble d actvtés, 2. D est un ensemble de données de procédé, 3. E c A A Conds(D ) est un ensemble de dépances de contrôle avec des condtons de transton défnes sur les éléments de D, 4. E d A A D est un ensemble de dépances de données, 5. S est un ensemble de servce composés. Les actvtés ont des denttés comme a. S une actvté nvoque un servce, elle la référence (vor Défnton 4.2.3). Les actvtés conversatonnelles qu référencent le même servce s sont regroupées dans un ensemble A s. Une dépance de contrôle e E c entre deux actvtés a et 59

76 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut c a j est notée a aj. De même, la dépance de donnée de deux actvtés a et a j est notée d aj. Une autre notaton concerne un chemn de contrôle qu rele deux actvtés. Celle-c est a notée comme un ordre partel a < a j. Défnton 5 (Actvté) Une actvté, a, P, est un tuple (In, Out, s, type) où : 1. In D est l ensemble des entrées de a, 2. Out D est l ensemble des sortes de a, 3. s S est le servce nvoqué par l exécuton de a, 4. type {wrte, read, local} est le type de a, Une actvté peut avor un certan nombre d entrées et de sortes. L actvté réfère un servce qu elle nvoque pour son exécuton par un moteur de procédé. L nteracton d un moteur de procédé avec un servce peut se fare de deux manères : la récepton ou l émsson d un message. Dans le premer cas, on parle d une actvté de type read alors que dans le deuxème cas on parle d une actvté de type wrte. Elles sont respectvement notées comme a r et a w. Un procédé peut auss nclure des actvtés qu n ont pas d nteracton avec un servce partculer. C est le cas des actvtés qu manpulent les varables ou les données locales au moteur d exécuton. Par exemple, une actvté qu crée une commande pour déclencher un processus de producton n a souvent pas beson d entrées à part un message de contrôle. Dans notre modélsaton, ce sont les actvtés de type local. Elles sont notées comme a l. Les actvtés ont des dépances entrantes et sortantes. En conséquence nous proposons deux ensembles qu les regroupent. Défnton 6 (Postset) Le postset d une actvté a est notée a. Ce derner content les actvtés dont a est la source de leur dépances rentrantes. Plus formellement, a ={a j A a c aj a d aj }. Le postset d une actvté est l ensemble des actvtés que ses dépances sortantes vsent. Ces dépances peuvent être des dépances de données et de contrôles. Exemple 1 (Postset) La fgure 5.3 llustre un exemple de procédé. Prenons l actvté a 2. a 2 a deux actvtés qu la suvent par le flux de contrôle : a 4 et a 5. Une trosème actvté, a 12, a une dépance de donnée avec a 2. Ans le postset de a 2, a 2 = {a 4, a 5, a 12 }. L actvté a 4 a une actvté qu la sut par le flux de contrôle. C est l actvté a 7. a 4 a une dépance de donnée avec l actvté a 19. En conséquence, a 4 = {a 7, a 19 }. Comme nous avons regroupé les actvtés qu sont vsées par les dépances sortantes, nous regroupons les actvtés qu sont à la source des dépances rentrantes dans un ensemble qu on appelle preset. 60

77 4.3. Prncpes de décentralsaton et l orgnalté de l approche Défnton 7 (Preset) Le preset d une actvté a est notée a. Ce derner content les actvtés dont a est la cble des dépances sortantes. Plus formellement, a = {a j A a j c a a j d a } Exemple 2 (Preset) Prenons l actvté a 19 du procédé llustré dans la fgure. L actvté a 19 a quatre dépances de donnée entrantes d 3, d 4, d 5 et d 6. Elles correspondent aux actvtés a 4, a 12, a 13 et a 9. L actvté a 19 a une dépance de contrôle entrante venant de l actvté a 18. Ans, le preset de l actvté a 19 est notée a 19 = {a 4, a 9, a 12, a 13, a 18 }. Jusqu c nous avons présenté les éléments de base d un procédé nter-organsatonnel qu caractérse la composton d un ensemble de servces. Nous allons étre ces défntons avec des concepts addtonnels. Avant de présenter les autres défntons, nous présentons les prncpes de base de la décentralsaton qu va trater ces spécfcatons. 4.3 Prncpes de décentralsaton et l orgnalté de l approche Comme nous avons soulgné pluseurs fos dans les chaptres précédents, notre approche est basée sur l exécuton de procédé coopérants dérvés à partr d une spécfcaton centralsée de telle sorte que les dépances du procédé centralsé soent re-étables avec des nteractons égal-à-égal entre les servces sous-jacents. La producton des procédés coopérants à partr de la spécfcaton centralsée est un tâche dffcle. Dans cette secton, nous présentons les cas problématques en général et nous cherchons à explquer comment nous les avons résolus d une manère systématque. Par la sute, nous rappelons certans éléments de fond qu servent de brques de base comme la sémantque des procédés dstrbués et la cohérence des procédés coopérants. Le premer pont concerne l étude des procédés décentralsés pour à la fos guder et dscplner le rasonnement dans l opératon de décentralsaton. Le second pont concerne la défnton des règles de transformaton et de constructon mécansables que nous proposons pour dérver les procédés coopérant à partr de la spécfcaton centralsée. Dans les deux étapes, nous explquons certanes orgnaltés comme : Un procédé peut contenr pluseurs types de dépances. Nous ne nous lmtons pas seulement à l analyse du flux contrôle contrarement aux nombreuses travaux lés comme [van der Aalst and Weske2001] [Sadq et al.2006] [Atlur et al.2001]. Nous consdérons le flux de données en même temps que le flux de contrôle. Nous étudons les dfférents types de dépances lées à la combnason de ces deux formes. En dehors de sa nature formelle, la décentralsaton nécesste la consdératon de l ntergcel sous-jacent. Pour cela nous nous ntéressons à la sémantque des procédés coopérants [Bultan et al.2006]. Cela nclut la communcaton synchrone, la communcaton asynchrone, les modes de lecture/écrture dans les connexons (channels) de communcaton etc. En conséquence, notre opératon de décentralsaton consdère les aspects fonctonnels ans que les aspects formels. Quand un procédé est décentralsé, une exgence naturelle est la préservaton de son comportement centralsé. Cette exgence nécesste une preuve clare et précse des opératons employées. L équvalence des comportements est une premère caractérstque mportante que nous sommes oblgés de vérfer avant d évaluer l apttude d une approche donnée à répondre aux dfférents besons. 61

78 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Avant de passer aux étapes suvantes, l est souhatable de rappeler quelques éléments de base que nous avons utlsé pour concrétser nos dées. Les servces Web, les procédés qu composent les servces comme des workflows, et les systèmes communcants en général sont basés sur des smples prncpes théorques. La sémantque des procédés dstrbués et coopérants Les procédés coopérants et dstrbués sont un sujet d étude depus de nombreuses années [Kahn1974]. Les notons théorques ben étables comme la communcaton, la concurrence et l équvalence sont concrétsées par les algorthmques parallèles, les worfklows, les grds et dernèrement les servces Web dans le domane nformatque. La sémantque de la communcaton sous-jacente chose nfluence drectement le rasonnement aux nveaux d abstracton plus hauts. La sémantque de la communcaton sous-jacente concerne la modélsaton de la structure de communcaton qu rele deux éléments communcants comme par exemple la talle de celle-c, les modaltés d écrture et de lecture concernées, ou la fablté. La sémantque des procédés communcants peut être vue comme l équvalence des traces ou l analyse du comportement des éléments communcants. Nous lmtons notre dscusson seulement à la structure des communcatons qu concerne la sute de notre contrbuton. Une structure de communcaton, souvent appelé un channel en anglas, rele deux enttés qu communquent. Dans les travaux théorques, elle est modélsé comme llustré dans la fgure 4.3. Dans des applcatons plus concrètes, l s agt d une espace mémore partagée par les deux enttés. Il est à noter qu un trosème entté peut l mplémenter s les enttés communcantes ne la partagent pas. Pant la communcaton, une entté communcante envoe des données dans cette structure et l autre reçot les données de la même manère. Pour communquer de cette manère, l entté expédteur exécute une actvté qu écrt la donnée dans le channel et l entté récepteur exécute une actvté qu lt la donnée à partr du channel. Dans notre spécfcaton, ce sont les actvtés de type wrter et read. Comme deux enttés communcantes sont ndépantes, elles peuvent exécuter ces actvtés également ndépamment l une de l autre. Cela peut poser un problème de synchronsaton. Quel dot être le comportement de l entté expédtrce s l entté réceptrce n est pas en un état d accepter la donnée envoyée? De même, qu est-ce qu l se passe s l entté réceptrce est dans l état récepton mas la donnée n exste pas dans le channel? Dot-elle contnuer son exécuton ou attre la donnée? Dans le cas où les deux enttés échangent pluseurs messages quelle est la poltque de lecture à partr du channel? Les réponses à ces questons smples défnssent la sémantque des procédés communcants. S les concepts de lecture/écrture et de channel peuvent être décrtes de manère abstrate, leur mplémentaton concrète se fat dans le contexte des servces Web [Barros et al.2005]. Les procédés communcants consdèrent deux modes de communcaton essentels : Synchrone et Asynchrone. La premère modalté nécesste une synchronsaton forte entre deux enttés qu échangent des données de telle sorte que les deux exécutent respectvement une actvté qu envoe la donnée et une actvté qu reçot la donnée envoyée. S une donnée envoyée n est pas reçue par son destnatare ou ben n est pas envoyée par son expédteur, les procédés exécutés par les enttés restent bloqués. La deuxème modalté est plus flexble. Le channel qu rele les deux enttés qu communquent peut avor une talle llmtée en théore et suffsamment grande en réalté. Comme la talle du channel est llmtée, le procédé qu envoe des données dans le channel n est pas bloqué même s le récepteur ne reçot pas les données en même temps. Pourtant, le procédé qu dot consommer les données reste bloqué tant qu l n y a pas de donnée dans le channel. Pour le procédé, on peut défnr des poltques de lectures comme FIFO, LIFO ou ben la lecture arbtrare. Pourtant cela ne change pas les lectures bloquantes à partr des channels. 62

79 4.3. Prncpes de décentralsaton et l orgnalté de l approche La communcaton asynchrone est la modalté utlsée sur l nternet ans que par les servces Web [Kazhamakn et al.2006]. La modalté synchrone peut être vue comme un cas restrent de la modalté asynchrone qu utlse un channel de talle lmtée à une seule donnée. Dans la sute, nous allons utlser la modalté asynchrone parce qu elle est la plus répandue dans les réalsatons concrètes. La modalté de lecture à partr des channels est la lecture arbtrare. Nous décrvons cette hypothèse plus formellement dans l hypothèse 8. Hypothèse 8 (Lecture arbtrare) La lecture à partr des channels de communcaton se fat d une manère arbtrare. N mporte quelle donnée présente peut être consommée par le procédé récepteur. Soulgnons auss que la fablté de communcaton est très mportante dans un contexte où les messages envoyés sur les channels peuvent être perdus qu rédusent séreusement la capacté d applcaton des autres restrctons ctées c-dessus. Nous fasons l hypothèse de channels fables en vue d évter les ambguïtés concernant les sémantques des procédés coopérants. Plus formellement, celle-c est décrte dans l hypothèse 9. Hypothèse 9 (Communcaton parfate) Les channels de communcatons entre les procédés sont parfats. Aucune donnée envoyée dans un channel n est perdue n duplquée. Cette hypothèse peut être faclement satsfate en utlsant les technologes récentes comme WS-RelableMessagng. Un Crtère de décentralsaton : Global Soundness Par rapport à la sémantque des procédés coopérants et aux notons d équvalence connues dans la lttérature [Mlner1999] [Krzysztof Apt1997], en 1999, Van Der Aalst a formulé un ensemble de crtères connu comme Global Soundness [van der Aalst1999]. Il s agt d une extenson de la noton de Soundness proposée par le même auteur dans ses travaux antéreurs [van der Aalst1998]. La noton de Soundness est un crtère de correcton pour un workflow centralsé qu est exécuté par une seule entté. Il peut être vérfé en utlsant les proprétés de lveness et boundedness des réseaux de Petr. Il est à noter que la modélsaton des procédés avec les réseaux de Petr est une hypothèse de ce traval. La mse en place de son approche consste à vérfer que le procédé se termne, et à sa termnason l n y a qu un seul jeton dans sa place termnale. Quant à la proprété du Global Soundness, en résumé, elle s ntéresse à la vérfcaton des procédés coopérants (ou ben nter-organsatonnels) avec des connectons (channels) synchrones et asynchrones. On peut consdérer le global soundness comme un ensemble de crtères mnmaux qu un procédé nter-organsatonnel dot satsfare. Dans un premer temps les communcatons prévues des procédés et les chemns qu ls peuvent prre pant leur exécuton sont examnés. Ensute, une technque de vérfcaton, qu est toujours basée sur les proprétés des réseaux de Petr, est ntrodute. Avec cette technque, on peut vérfer s l exste des stuatons bloquantes dans les chemns possbles. Ensute, la proprété du Global Soundness ntrodut des crtères smlares à ceux de la proprété de soundness : chaque procédé dot se termner et à sa termnason, l ne dot comporter qu un seul jeton dans sa place de termnason. 63

80 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut 1 LWF1 LWF2 2 t1 ac1 t11 p1 p2 p11 t2 t3 t4 t5 t12 t13 ac2 p3 p4 p12 t6 t7 sc1 t14 p5 p6 p13 t8 ac3 t15 o1 o2 Fgure 3: An nterorganzatonal workflow composed of two local workflows. Fg. 4.3 L exemple de Global Soundness [van der Aalst1999] used to model causal depences, e.g., task t11 n LWF2 has to wat for the completon Cela ofveut taskdre t1 nque LWF1. tousthe les messages synchronous envoyés communcaton dovent être element consommés sc1 par forces leurs thedestnatares. transtons t7le derner and t14 crtère to be n est executed pas une at stuaton the same bloquante tme. Synchronous qu empêche communcaton l exécuton, mas corresponds l n est pas to souhatable pour la termnason approprée des procédés. Certans travaux pertnents [Wombacher2006] the meltng of a number of transtons, therefore we also use the term fuson set to denote a [Kndler et al.2000] étudent le global soundness dans un contexte décentralsé tout en respectant synchronous communcaton element. Defnton 7 formalzes the concept of an nterorganzatonal workflow. le traval orgnal. Le problème essentel qu ls essaent de résoudre est la vérfcaton de global soundness sans avor une vue globale des procédés coopérants. Defnton 7 (IOWF) An Interorganzatonal Workflow (IOWF) s a tuple Exemple IOWF 3 = (Global (PN 1, PN Soundness) 2,..., PN n, P La AC fgure, AC, 4.3 T SC llustre, SC ), un where: exemple de procédés nter-organsatonnel prs du paper orgnal de Van Der Aalst[van der Aalst1999]. Il s agt de deux procédés coopérants, LWF1 et LWF2, modélsés avec des réseaux de Petr. En conséquence, seulement le flux () n IN s the number of local workflow nets, de contrôle () forest each consdéré. k {1, Il..., yn}: a quatre PN k éléments s a WF-net de communcatons, wth source placeac1, k and ac2, snk sc1place et ac4. o k, Ils décrvent les communcatons des actvtés correspondantes. Par exemple, l actvté t11 dans LWF2 dot () attre for all la compléton k, l {1,..., den}: l actvté fk l, t1then dans(p LWF1. k T k ) L élément (P l synchrone T l ) =, sc1 force des actvtés t7 et t14. (v) T Consdérons = k {1,...,n} T que k,p LWF1 = exécute k {1,...,n} P l actvté k,f t4 = et LWF2 k {1,...,n} F exécute t12. Dans ce cas, le message qu est assocé à ac2 n est pas traté comme l faut. Parce que k, le message envoyé par LWF2 par ne sera jamas consommé par LWF1 parce qu l ne pr pas ce chemn. En conséquence, (v) même P AC ss the LWF2 set of n est asynchronous pas bloqué, communcaton l ne peut pas termner elements correctement (communcaton par places), rapport aux crtères de global soundness. Consdérons mantenant, les actvtés t5 et t12. S LWF1 exécute (v) T SC s the set of synchronous communcaton elements (fuson sets), t5, l va attre le message que LWF2 dot fournr à travers ac2. Plus précsément, ce message est fourn (v) Ppar AC t12t SC que=, LWF2 (P AC dot exécuter. T SC ) (P Pourtant, T ) s=, LWF2 pr le chemn de l actvté t13, l actvté t12 n est jamas exécutée. En conséquence, LWF1 reste bloqué. 64

81 4.3. Prncpes de décentralsaton et l orgnalté de l approche préparer la lvrason nspecton rembourses effectuer la lvrason préparer le rapport Fg. 4.4 L élmnaton des chemns morts dans une exécuton centralsée Comme l exemple 3 l llustre, les crtères de cohérence des procédés coopérants sont smple à comprre mas dffcle à vérfer. Dans un premer temps les technques de vérfcaton nécesstent la spécfcaton des procédés locaux présents dans le procédé nter-organsatonnel. Dans le cas contrare, les approches alternatves peuvent être utlsées. Dans notre traval, nous ne cherchons pas à vérfer la cohérence des procédés locaux exstants. Contrarement à la majorté des travaux exstants, notre but n est pas la vérfcaton de la cohérence des procédés coopérants. Nous produsons des procédés coopérants à partr d une spécfcaton complète centralsée. En conséquence, le crtère peut être vérfé à la fn de l opératon. La conformté de la réalsaton pour chaque nveau de la concepton en commençant par les partes les plus élémentares pus en remontant progressvement jusquau procédé enter. Pour cela, en correspondance à chaque phase de la transformaton est assocée une phase de test et d évaluaton de la conformté. Ans, les deux démarches descante et ascante sont complémentares. L Élmnaton des chemns morts (Dead Path Elmnaton) : Conformément à ce qu a été dt précédemment, notre approche met en œuvre la sémantque de la spécfcaton centralsée dans une exécuton décentralsée. L élmnaton des chemns morts (DPE) est un processus partculer que les moteurs d exécuton de procédé supportent. Il s agt des spécfcatons dans lesquelles un pont de jonture peut causer un problème de synchronsaton. L mplémentaton de ce processus dans un moteur d exécuton centralsé n est pas dffcle. Mas l est à noter que certans moteurs d exécuton ne le supportent pas [Leymann and Roller2000] à cause des dffcultés lées à l mplémentaton. Ce processus a un rôle mportant dans une exécuton décentralsée où les dépances de données et de contrôles peuvent co-exster. Nous allons utlser les prncpes de DPE pour concrétser nos algorthmes. Avant de passer à la sute, nous rappelons brèvement ce prncpe. Exemple 4 (L élmnaton des chemns morts) Nous consdérons le fragment de procédé llustré dans la fgure 4.4. La premère actvté est l actvté nspecton. Après l exécuton de cette actvté, la réclamaton peut être remboursée ou refusée. S la réclamaton est remboursée, l actvté rembourser est exécutée snon cette actvté n est pas exécutée. Les actvtés préparer le rapport et préparer la lvrason sont exécutées dans les deux cas. L actvté effectuer la lvrason est exécutée après la termnason de toutes les actvtés précédentes actvées. Dans cet exemple l actvté rembourser peut être suspue. La problématque est la termnason des actvtés préparer la lvrason et préparer le rapport n est pas suffsante pour l actvaton de l actvté effectuer la lvrason : l faut savor s l actvté rembourser est actvée ou pas. La suspenson de l actvté rembourser dot être consdérée par le système de geston de procédé pour évaluer les condtons d actvaton de effectuer la lvrason. Cette opératon s appelle l élmnaton des chemns morts (Dead Path Elmnaton, DPE en anglas). 65

82 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Moteur d'exécuton a a j s s j Fg. 4.5 Une dépance de contrôle entre deux actvtés qu évoquent des servces dfférents La décentralsaton d un procédé centralsé Dans cette secton, nous présentons notre technque de transformaton qu dérve les procédés coopérants à partr d une spécfcaton centralsée. Nous commençons par explquer l opératon qu dérve les procédés coopérants par des exemples ntutfs pus nous détallons comment nous maîtrsons les cas essentels ans que les cas problématques. Prenons deux actvtés a et a j dépantes d une spécfcaton centralsée par une dépance de contrôle. Admettons que ces deux actvtés correspondent aux nteractons entre deux servces dfférents respectvement s et s j comme llustrée dans la fgure 4.5. Quand un moteur d exécuton exécute la spécfcaton centralsée, d abord a est exécutée et sute à la termnason de son exécuton a j est exécutée. Pant ce processus, les deux servces sous-jacents s et s j n ont pas d nteracton drectes. Ils sont évoqués par le moteur d exécuton qu exécute a et a j. Comme nous l avons déjà soulgné, nous voulons que s et s j aent des nteractons drects quand ls sont choss pour cette composton. Pour ce fare, nous allons fournr deux procédés qu seront dynamquement assocés aux servces s et s j de telle sorte que cette dépance sot une nteracton d égal-à-égal entre s et s j. Nous appelons ces deux procédés P s et P sj. La premère queston de la transformaton est : Quelles sont les actvtés de ces procédés? La seconde queston est : Comment sont elles structurées? Dans le cas c-dessus, P s dot nformer P sj à propos de la termnason de son opératon. Dans ce cas a dot être exécutée par P s et a j par P sj. Cela évte des messages de contrôle nutles entre s, s j et le moteur d exécuton qu devat exécuter la spécfcaton centralsée. Il est à noter que le contenu de la donnée échangée lors d un échange drecte de contrôle de deux fragments n est pas le même qu un échange drecte de données. La fgure 4.14(a) llustre les deux procédés P s et P sj dérvés à partr de la spécfcaton de la fgure 4.5. S cet exemple est smple, l explque ben le prncpe de base de l opératon de décentralsaton qu dérve les procédés coopérants. En partant de ce prncpe smple nous présentons d autre type de fragments de procédé et nous essayons d explquer la généralsaton de cette opératon. Exemple 5 (Le cas d une dépance de donnée) La fgure 4.6 llustre un fragment d un procédé centralsé dont nous voulons dérver les procédés coopérants. Par rapport à l exemple précédent, ce fragment a une dépance de donnée qu rele deux actvtés qu sont sur le même flot de contrôle llustré par un nuage. Quand l actvté source et l actvté cble sont placées dans les fragments coopérants, l est préférable que cette dépance de donnée sot mplémentée 66

83 4.3. Prncpes de décentralsaton et l orgnalté de l approche d k a 1 :s 1 a 2 :s 2 Fg. 4.6 L exemple de dépance de donnée sur un chemn de contrôle comme une nteracton d égal-à-égal entre les deux procédés fourns. Comme l actvté source et l actvté vsée n ont pas la possblté d être suspues, cette dépance peut être mplémentée en plaçant une actvté d écrture dans le fragment qu contra l actvté source et une actvté de lecture dans le fragment récepteur. Pourtant une dfférence mportante par rapport au cas précédent qu l ne faut pas oubler est que le contenu du message échangé est la donnée concernée et pas un message de contrôle. Exemple 6 (Le cas d une dépance de donnée depus un chemn non-exécutable) La fgure 4.7 llustre un fragment d un procédé centralsé. Il s agt de deux actvtés a 1 et a 2 qu évoquent respectvement deux servces s 1 et s 2. Dans une exécuton centralsée s l actvté a 1 est exécutée, une de ses sortes est utlsée comme une des entrées de a 2. S l actvté a 1 n est pas exécutée, l entrée de a 2 ne sera pas ntalsée avec la sorte de l actvté a 1. a 1 :s 1 d k a 2 :s 2 Fg. 4.7 Un exemple de fragment où deux actvtés sont relées par une dépance de donnée Quand on dérve deux fragments coopérants pour mplémenter cette relaton en vue de fare nteragr deux servces pour l échange de la donnée d k, on dot consdérer explctement le fat que l actvté source pusse être suspue. Parce que s l actvté source est suspue, elle ne peut pas fournr une donnée à envoyer à a 2 qu sera dans le fragment P s2. Dans ce cas, l actvté qu dot recevor la donnée attue est bloquée jusqu à ce que cette donnée sot fourne. Comme cette donnée n est jamas envoyée de P s1 à P s2, P s2 sera bloqué. Cec est le résultat de la sémantque des procédés coopérants que nous avons présentés dans les sectons précédentes où une actvté de lecture reste bloquée tant qu l n y a pas de donnée à lre. L exemple 6 llustre une stuaton dans laquelle la démarche ntutve de l opératon qu fournt 67

84 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut les procédés coopérants cause un problème de blocage. En conséquence, l opératon dot être reformulée pour trater ce cas. Exemple 7 (Le cas d une dépance de donnée vers un chemn non-exécutable) La fgure 4.8 llustre un fragment d un procédé centralsé. Nous nous ntéressons à une dépance entre deux actvtés a 1 et a 2 qu évoquent respectvement s 1 et s 2. Contrarement à l exemple précédent, l actvté cble de la dépance de donnée d k peut être suspue dans une exécuton centralsée. Étant donné que les exécutons décentralsées et centralsées sont équvalentes, l actvté vsée qu sera placée dans P s2. La suspenson de l actvté a 2 ne cause pas une stuaton de blocage pour P s1 comme les actvtés d écrture ne sont pas bloquantes. Cela veut dre que P s1 ne sera pas bloqué après avor envoyé la donnée de sorte à P s2. d k a 2 :s 2 a 1 :s 1 Fg. 4.8 Un exemple de fragment où deux actvtés sont relées par une dépance de donnée Pourtant s la donnée n est pas reçue par un procédé, P s1 ne peut pas termner correctement pusqu l va avor une donnée non-consommée dans un de ses canaux de communcaton. Encore une fos, l opératon ntutve présentée pour l mplémentaton décentralsée d une dépance de contrôle ou de donnée ne satsfat pas les crtères que les procédés coopérants dovent vérfer. Comment mplémenter l élmnaton des chemns morts? Après la présentaton des exemples qu détallent les cas spécfques que l opératon de décentralsaton dot gérer, nous détallons notre approche. Cette dernère est basée sur l extenson du processus DPE (Dead Path Elmnaton) classque. Dans un premer temps, cette extenson trate la spécfcaton centralsée à décentralsée pus les résultats de ce tratement sont utlsés pour l mplémentaton de l opératon elle-même. Intutvement, nous pouvons explquer cette approche en utlsant l exemple de motvaton du chaptre présent (cf. la fgure 5.3). Le procédé llustré nclut des ponts OR-splt depus lesquels un DPE qu pr un ou pluseurs des chemns sortants peut être lancé. Un DPE lancé est la rason de la suspenson des actvtés qu sont sur le chemns prs par le DPE. Ans, les actvtés qu sont vsées par les dépances de donnée venant des chemns prs sont nfluencées ndrectement. Exemple 8 (L exemple de motvaton de l approche) La fgure 4.9 llustre un procédé. Nous supposons qu au pont OR-splt qu sut l actvté a 6, DPE est lancé. Nous supposons que DPE pr le chemn qu nclut a 8 et a 9. Il est à noter que ce chemn se termne au pont ORjon qu précède l actvté a 17. Les actvtés nfluencées par ce DPE sont essentellement a 8 et 68

85 4.3. Prncpes de décentralsaton et l orgnalté de l approche Les actvtés nfluencées s le chemn vers a8 d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 d4 a2 a13 a14 d2 a12 a18 a19 a20 a5 a15 a16 a7 Les actvtés qu sont nfluencées s le chemn vers a4 est prs par DPE a4 d3 d5 Fg. 4.9 Les exemples d actvtés nfluencées par le DPE a 9. Mas a 9 fournt une sorte que a 19 dot utlser comme une de ses entrées. En conséquence, cette actvté est auss nfluencée de ce DPE. S on pr le pont OR-splt qu sut l actvté a 2, un DPE qu pr le chemn de l actvté a 4 ou a 5 peut être lancé. S l actvté a 4 est prse par le DPE, l actvté a 19 sera nfluencée pusqu elle att une des entrées de a 4. L exemple c-dessus montre les conséquences de DPE quand on veut dérver les fragments coopérants d un procédé centralsé. En vue de généralser les dépances que nous avons présenté, nous utlsons deux défntons qu étent les défntons mentonnées dans les secton précédentes. La premère défnton est le postset étu. Un postset étu est assocé aux actvtés à partr des quelles un DPE peut être lancé. Le postset étu content des actvtés qu peuvent être nfluencées par le lancement du DPE. Comme nous l avons explqué, ce ne sont pas seulement les actvtés qu sont sur le chemn de contrôle prs par le DPE mas auss les actvtés qu ont des dépances de données rentrantes venant de ces derners. Plus formellement, nous pouvons défnr le postset étu comme c-dessous. 69

86 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Défnton 10 (Postset étu) Le postset étue, a, d une actvté a est composé par tros sous-ensembles d actvtés notés a = a F ad,f a D,T où 1. a F est l ensemble des actvtés qu sont sur les chemns prs par le DPE lancé après l exécuton de l actvté a. Plus formellement, a F = c (a j a ) a aj a F,a j où a F,a j = {a z A (a j < a z a z < â )} 2. a D,F est l ensemble des actvtés qu ont des dépances de donnée avec des actvtés qu sont sur les chemns prs par le DPE lancé sute à l exécuton de l actvté a. Plus formelle,ent, a D,F = c a j a a aj a D,F,a j où a D,F,a j = {a k A a l A, a j < a l a l < â, a l d az } 3. a D,T est l ensemble des actvtés qu ont des dépances de données avec des actvtés qu ne sont pas prses par le DPE lancé sute à l exécuton de l actvté a. Le chemn de a ne content pas d autre ponts de OR-splt jusqu à l actvté en queston. Plus formellement, a D,T = c (a j a a aj ) ad,t,a j où a D,T,a j = {a k A a l A, a m A, (a j < a l a l < â ), a l d ak, a m est une actvté OR-splt, (a j < a m a m < a k ) } Exemple 9 (Postset étu) La fgure 5.3 llustre un exemple de procédé que nous avons présenté en détal dans la sous-secton Prenons l actvté a 1 et dentfons son postset étu. L actvté a 1 est une actvté de OR-splt où le DPE pr le chemn qu commence avec l actvté a 2 ou celu qu commence avec l actvté a 3. Le postset de l actvté a 1, a 1 nclut deux actvtés lées à a 1 par le flux de contrôle. Plus précsément, a 1 = {a 2, a 3 }. Le postset étu, a, de l actvté a est composé par tros sous-ensembles notés a = a F ad,f Le premer sous-ensemble a F 1 est composé comme sut. af 1 = af,a 2 1 a F,a 3 actvtés sont dépantes par rapport au flux de contrôle. a F,a 2 a D,T. 1 comme ces deux 1 nclut les actvtés qu dovent être suspue s le chemn vers a 2 est prs par DPE jusqu au pont de OR-jon correspondant à a 12. Ans, a F,a 2 1 = {a 4, a 5, a 7 } et a F,a 3 1 = {a 6, a 8, a 9, a 10, a 11, a 17 } (vor. la fgure 4.10). S les actvté de a F 1 sont prses par DPE et ne sont pas exécutées alors les autres actvtés qu dovent utlser les sortes de ces actvtés dovent être nformées. Ans, a D,F 1 nclut deux sousensembles a D,F,a 2 1 et a D,F,a 3 1. a D,F,a 2 1 nclut les actvté qu seront nfluencées s le chemn de l actvté a 2 est prs par DPE lancé sute à l exécuton de a 1. a D,F,a 2 1 = {a 12, a 17 } (vor la fgure 4.11) parce que, a 2 et a 12, et a 4 et a 17 ont des dépances de données. De même, a D,F,a 3 1 = {a 19 }. Le derner sous-ensemble de a 1 est a D,T 1 composé lu-même de deux sous-ensembles a D,T,a 2 1 et a D,T,a 3 1. a D,T,a 2 1 nclut les actvtés qu dovent être nformées s le chemn de l actvté a 2 n est pas prs par DPE. a D,T,a 2 1 = {a 12 }. Il est à noter que l actvté a 4 peut être prse par DPE lancé sute à l exécuton de l actvté a 2. Pour cette rason, elle n est pas dans a D,T,a 2 1. a D,T,a 3 1 =. 70

87 4.3. Prncpes de décentralsaton et l orgnalté de l approche d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg Les dépances qu appartennent à a F,a 3 1 Les éléments de postset étu sont regroupés en foncton des dépances sous-jacentes de donnée ou de contrôle. Cec faclte leur tratement dans les étapes suvantes. Le postset étu est le rasonnement sur les dépances du pont de vue de l actvté qu lance le DPE. Nous devons éventuellement modélser les dépances lées à l extenson de DPE de la part des actvtés qu sont vsées par les dépances étues. Pour ce fare, nous proposons d assocer un préset étu à chaque actvté qu est susceptble d être vsé par une dépance étue venant d une actvté qu précède un pont OR-splt. Plus formellement, nous défnssons un preset étu comme c-dessous. 71

88 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg Les dépances qu appartennent à a D,F,a 2 1 Défnton 11 (Preset étu) Le preset étue, a, d une actvté a est composé par tros sous-ensembles d actvtés notés a = a F a D,F a D,T où 1. a F est l ensemble des actvtés à partr desquelles DPE peut être lancé et pr le chemn de l actvté a. Plus formellement, a F = {a k A a z est une actvté de OR-splt, a z < a a < â z } 2. a D,F est l ensemble des actvtés à partr de desquelles DPE peut être lancés vers les actvtés sources des dépances de données entrantes avec a. Plus formellement, a D,F a F,a j = (a j a a j d a ) ad,f,a j = a F j où est l ensemble des actvtés OR-splt qu précédent les actvtés sources des dé- 3. a D,T pances de données entrantes de a. a D,T = (a j a a j d a ) ad,t,a j a D,T,a j = {a k A a l A, a k, a l sont des actvtés OR-splt, (a k < a j a j < â k ) (a k < a l a l < a j a j < â l )} où Exemple 10 (Preset étu) La fgure 5.3 llustre un procédé. Prenons l actvté a 8 pour dentfer son préset étu. Le preset étue, a 8, de l actvté a 8 est composé par tros sousensembles. Formellement, a 8 = a F 8 ad,f 8 a D,T 8. L actvté a 8 peut être prse par deux DPE dfférents lancés respectvement à partr des actvtés a 1 et a 6. Ans, a F 8 = {a 1, a 6 } (vor la fgure 4.12). Comme l actvté a 8 n a pas de dépance de donnée venant d une autre actvté 72

89 4.4. Les algorthmes pour la producton des fragments coopérants d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg Les dépances qu appartennent a F 8 a D,F 8 et a D,T 8 sont des ensembles vdes. Consdérons l actvté a 19 qu a quatre dépances de donnée rentrantes et une seule dépance de contrôle rentrante. Le preset de a 19 est a 19 = {a 4, a 9, a 12, a 13, a 18 }. De même, le preset étu de l actvté a 19 est composé de tros sous-ensembles a 19 = a F 19 ad,t 19 a D,F 19. L actvté a 19 n est pas sur un chemn qu peut être prs par DPE. Pour cette rason a F 19 est un ensemble vde. Pourtant, les actvtés dont a 19 a des dépances de donnée rentrantes peuvent être prses par DPE. a D,F 19 (vor la fgure 4.13) est composé de quatre sous-ensembles. a D,F 19 = a D,F,a 4 19 a D,F,a 9 19 a D,F,a a D,F,a Entre eux, a D,F,a et a D,F,a sont des ensembles vdes comme a 12 et a 13 ne sont pas sur les chemns prs par DPE. a D,F,a 4 19 nclut les actvtés à partr de la quelle DPE qu pr le chemn de l actvté a 4 peut être lancé. a D,F,a 4 19 = {a 1, a 2 } et a D,F,a 9 19 = {a 1, a 6 }. a D,T 19 = ad,t,a 4 19 a D,T,a a D,T,a 4 19 est un sngleton qu nclut la dernère actvté OR-splt à partr de la quelle DPE qu pr a 4 peut être lancé. a D,T,a 4 19 = {a 2 }. Parellement, a D,T,a 9 19 = {a 6 }. 4.4 Les algorthmes pour la producton des fragments coopérants Dans les sectons précédentes, nous avons présenté notre approche en général avec les structures de données qu concrétsent les prncpes de l approche. Dans cette secton, nous présentons les algorthmes détallés qu tratent ces structures de données en vue de produre les procédés coopérants pour une exécuton décentralsée. Nous commençons sur les explquer par des exemples ntutfs avant de donner leur spécfcaton formelle. 73

90 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg Les dépances qu appartennent à a D,F Vue d ensemble et présentaton ntutve des algorthmes Comme nous avons mentonné c-dessus, le but essentel des algorthmes est de systématser le processus de producton des procédés coopérants. Dans un premer temps, on dstngue deux opératons essentelles que les algorthmes dovent trater. La premère opératon est l nterconnexon des actvtés orgnales placées dans les procédés coopérants les unes avec les autres par des actvtés de lecture et d écrture. La deuxème opératon essentelle est la structuraton des actvtés connectées par rapport à leur nature conversatonnelle. Cec a pour but de respecter l ordre partel et en conséquence la sémantque de l exécuton. En fasant ces opératons, nous cherchons à répondre aux queston suvantes : quelles sont les actvtés de lecture et d écrture qu permettent l nterconnexon des actvtés structurées dans les procédés fourns? quelles sont les actvtés conversatonnelles structurées connectées dans les procédés? quels sont les contenus des messages échangés entre les procédés coopérants? La modélsaton des procédés tent compte de pluseurs aspects modélsés ndépamment du flux de contrôle. C est par exemple le cas du flux transactonnel du procédé ou ben de la geston des drots des accès. S la dmenson transactonnelle est essentelle pour une exécuton fable, nous ne nous ntéressons pas à la modélsaton et la décentralsaton du flux transactonnel. Mas nous explquons brèvement comment l approche présentée peut être étue vers la modélsaton des aspects transactonnels. La fgure 4.14 llustre comment les fragments coopérants sont produts à partr des concepts présentés dans la secton précédente. Comme nous l avons déjà précsé, l approche présentée est ntutve. La fgure 4.14(a) présente un fragment de procédé qu nclut deux actvtés a 1 et a 2 qu évoquent respectvement deux servces s 1 et s 2. La parte gauche de la même fgure llustre les fragments coopérants qu mplémentent la même dépance de contrôle avec deux procédés exécutés par s 1 et s 2. Ces procédés sont notés P s1 et P s2. Le message échangé entre les fragments P s1 et P s2 consste en un message de contrôle qu caractérse la termnason correcte de a 1 dans P s1 en vue d actver a 2 dans P s2. La fgure 4.14(b) llustre une dépance de donnée et son mplémentaton d égal-à-égal entre deux fragments de procédés exécutés par les servces 74

91 4.4. Les algorthmes pour la producton des fragments coopérants a 1:s 1 P s1 P s2 a 2:s 2 a 1:s 1 wrte(c) read(c) a 2:s 2 (a) a 1:s 1 a 2:s 2 d P s1 a 1:s 1 wrte(d) read(d) P s2 a 2:s 2 (b) P s1 a 1:s 1 d a 1:s 1 wrte(d) skp(c) P s2 a 2:s 2 a 2:s 2 (c) read(c) read(d) P s2 a 1:s 1 a 2:s 2 d (d) P s1 wrte(d) read(d) a 2:s 2 a 1:s 1 skp(c) Fg Les cas prncpaux qu dovent être consdérés en fournssant les fragments de procédés évoqués. Il est à noter que, le contenu du message échangé est une donnée de procédé et pas un message de contrôle qu actve l actvté a 2 dans P s2. Cet nteracton peut être mplémentée de la même manère pour chaque dépance de donnée qu connecte deux actvtés dans la spécfcaton centralsée. La fgure 4.14(c) et la fgure 4.14(d) llustrent deux cas plus partculers qu nécesstent un tratement spécal pour fournr les procédés coopérants. Les stuatons problématques de ces deux cas sont présentées précédemment. Ces fgures n llustrent que d une manère superfcelle les procédés dérvés des spécfcatons centralsées. Dans la fgure 4.14(c), le deuxème procédé qu dot recevor la sorte de l actvté a 1 reçot l état d exécuton de cette actvté avant d exécuter l actvté qu recevra sa sorte. Dans ces llustratons, nous ne sommes pas concernés par l orgne des messages reçus qu sont explqués dans les exemples précédents. Dans la fgure 4.14(d), la termnason approprée du premer procédé est assurée par un message d annulaton qu permet à ce derner de vder ses canaux de communcatons. Il est à noter que ces llustratons ne contennent pas la totalté des actvtés qu permettent la communcaton avec des autres procédés. Dans les sous-sectons suvantes, nous présentons la spécfcaton précse pour la structuraton des actvtés d nterconnexon. Le mécansme de producton des procédés, d un pont de vue algorthmque, trate 3 cas prncpaux. Le premer cas est la structuraton des actvtés qu permettent l nterconnexon d une actvté avec les autres actvtés sute à son exécuton dans le fragment assocé. Cette parte est explquée dans la secton Interconnexon avec les actvtés de postset et de postset étue. Dans cette parte, nous détallons comment un procédé dot se comporter après l exécuton d une actvté qu appartent à la spécfcaton centralsée et qu est placée dans ce procédé. Le deuxème cas que nous étudons est le comportement d un procédé avant d exécuter une actvté. Il s agt de l Interconnexon avec les actvtés de preset et de preset étue. Le trosème cas porte sur la structuraton des actvtés connectées au sen 75

92 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut des procédés coopérants pour préserver leur ordre partel dans la spécfcaton centralsée. Dans les sectons suvantes nous donnons une présentaton ntutve des algorthmes que nous avons développées pour formalser ces tros cas. Nous donnons également le résultat des algorthmes correspondantes applqués à nos exemples de motvaton. La sous-secton suvante présente les notatons que nous avons utlsées pour décrre les algorthmes Notatons Dans les notatons, les actvtés de connexon qu envoent et reçovent les messages sont notées respectvement comme a w et a r pour wrte et read en anglas. Comme les actvtés normales, elles évoquent des servces. Les messages échangés par l exécuton des actvtés de connexons sont les messages de contrôle qu peuvent suspre l exécuton d une actvté ou ben une autre actvté de connexon. En outre, ls peuvent échanger des données. Nous proposons le format suvant : Défnton 12 (Message) Un message est un tuple de la forme <actvty, commande, data, actvty source> où actvty A, commande {skp, exec}, data D et actvty source A. Dans ce format de message, un message de type < a, exec > ou < a, skp > veut dre que l actvté a dot être respectvement exécutée ou suspue. S l actvté a est précédée par pluseurs actvtés dans la spécfcaton centralsée, tous les messages correspondant de < a, exec > dovent être reçus. Mas s l actvté est sur un chemn qu pourrat être prs par un DPE, l sufft qu un seul message de < a, skp > sot reçu. Il est à noter que dans ce type de message le trosème et le quatrème éléments sont null et n ont pas d effet. S le message échangé est une donnée de procédé le message a pour contenu < a, d, a j > ce qu veut dre que le message content la donnée d que a va utlser et que a j a déjà fourne. S le message vse la suspenson d une actvté qu est censée recevor un message de contrôle, le message a le contenu suvant < a, skp, d, a j >. Le derner veut dre que l actvté qu dot recevor la donnée d que a dot utlser et que a j a fourne, dot être suspu parce que l actvté a j n est pas exécutée. Il est à noter que l dentté du servce qu émet le message n est pas nclut dans le message. Celle-c est dans la descrpton de l actvté qu va recevor le message éms. S on consdère les analyses que nous avons fates dans le chaptre précédent, le contenu des messages que les servces composés vont échanger lors de l exécuton des procédés est relatvement smple et ne nécesste pas d un tratement spécal qu on ne peut pas mplémenter dans la logque d un procédé. Les actvtés qu permettent la connexon des actvtés avec les autres actvtés dépantes sont ajoutées dans les procédés coopératfs de manère tératve comme par exemple pour chaque élément d un ensemble de preset ou d un preset étu. Nous utlsons les opératons d ajout aux fragments qu composent les procédés coopérants fourns. Ces opératons sont notées, et +. Elles caractérsent la structuraton de leurs opérandes dans le fragment fourn. Par exemple, le premer opérateur consste à ajouter ses opérandes dans un fragment AND-splt/AND-jon. Un fragment qu précède une actvté a est caractérsé par a et un fragment qu succède une actvté a est caractérsé par ã. S on consdère les opératons qu ajoutent des actvtés de connexons dans ces fragments, on peut donner comme exemples ã a w k et ã a w l. La dernère veut dre que les actvtés a w k +aw l sont structurées d une manère concurrente dans le 76

93 4.4. Les algorthmes pour la producton des fragments coopérants fragment ã. L exemple suvant ã a w k aw l et ã a w m a w n décrt l addton concurrente de quatre actvtés dans ã qu sont exclusve entre elles Interconnexon avec les actvtés de postset et de postset étue Après avor exécuté une de ses actvtés, le comportement d un procédé coopérant est naturellement d nformer les procédés qu contennent les actvtés qu suvent cette actvté dans la spécfcaton centralsée. Les sortes de l actvté dovent être transférées vers les actvtés qu dovent les utlser. S l actvté exécutée est une actvté de type OR-splt, le processus de l élmnaton des chemns morts dot être lancé après l évaluaton des condtons de transfert. En conséquence, on peut résumer les actvtés d nterconnexon d un procédé coopérant qu dovent suvre une actvté a appartenant à la spécfcaton centralsée : Les actvtés qu envoent les messages de contrôle aux actvtés qu la suvent par les dépances de contrôle, Les actvtés qu envoent les messages de contrôle aux actvtés qu sont sur les chemns qu seront élmnés en foncton de l évaluaton des condtons de transton, Les actvtés qu envoent les messages de données qu contennent les sortes de l actvté exécutée, L algorthme 1 détalle la structuraton de ces actvtés dans le procédé après une actvté a de la spécfcaton centralsée. L algorthme 1 trate les dépances en dfférent groupes pour structurer les actvtés de connexon. Informellement nous résumons comme sut. Comme nous l avons soulgné, la sorte de cet algorthme est le fragment qu dot être exécuté après a. Ce derner est nommé ã. Le fragment ã est composé de pluseurs fragments. Le fragment ãt,a j content les actvtés de connexons qu envoent des messages de contrôles pour l exécuton des actvtés suvantes dépantes par rapport au flux de contrôle. Le fragment ãt,a j nclut les actvtés qu vennent après l actvté a j. Comme les messages de contrôle d exécuton sont envoyés seulement aux actvtés du postset dépantes par rapport au flux de contrôle, le fragment ãt,a j content une actvté de connexon qu envoe le message de contrôle au procédé de l actvté a j. S l actvté pour laquelle l algorthme 1 est exécuté, la condton de transton vers ses actvtés de postset peut devenr f ausse. Les actvtés de connexon qu envoent des messages de contrôle de suspenson concernent toutes les actvtés qu sont prses par le DPE. Le fragment ãf,a j nclut les actvtés de connexon qu envoent des messages de contrôle de suspenson qu suvent l actvté a j jusqu au pont de jonture. Il est clar que les fragments ãt,a j exclusvement. Les fragments a D,F,a j et a D,T,a j et ãf,a j sont structurés, qu sont ajoutés respectvement aux ãf,a j et ãt,a j respectvement, consdèrent les actvtés cbles des dépances de données dont les actvtés sources sont prses par le DPE vers l actvté a j. Les actvtés de connexon de ãf,a j envoent des messages de suspenson aux procédés des actvtés cbles de dépances. De même, les actvtés de ãt,a j envoent des messages d exécuton aux procédés des actvtés sources. Le derner fragment ajouté à ã est le fragment qu content les actvtés de connexon qu envoent les sortes de l actvté a. Ce fragment est nommé ãd. Pour explquer la structuraton de l nterconnexon avec les éléments du postset nous utlsons l exemple suvant. 77

94 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Input : La spécfcaton centralsée de la composton Output: a A, ã forall s S do forall a A s do c forall a j a a aj do s j = servce(a j ); a T,a j a w (s j, < a j, exec >) c forall a j a a aj do forall a k a F,a j où a F,a j a F do s k = servce(a k ); a F,a j a w (s k, < a j, skp >) forall a k a D,F,a j où a D,F,a j a D,F do s k = servce(a k ); a D,F,a j a w (s k, < a, skp, d, a j >) forall a k a D,T,a j où a D,T,a j a D,T do s k = servce(a k ); a D,T,a j a w (s k, < a, exec, d, a j >) d forall a j a a aj do s j = servce(a j ); a D a w (s j, < a j, d, a >) c forall a j a a aj do ã ãt,a j ãf,a j ã ãd Algorthm 1: Interconnexon avec les actvtés de postset et de postset étue Exemple 11 (Interconnexon avec les actvtés de postset et de postset étue) Nous consdérons l exemple de motvaton llustré dans la fgure 5.3. Nous prenons l actvté a 1 afn de la structurer dans un procédé. Dans son postset a 1 l y a deux actvtés, a 1 = {a 2, a 3 }. Dans son postset étue, a F 1 on trouve af,a 2 1 et a F,a 3 1. Ces ensembles sont respectvement a F,a 2 1 = {a 4, a 5, a 7 } et a F,a 3 1 = {a 6, a 8, a 9, a 10, a 11, a 17 }. Dans a D,F 1, on trouve a D,F,a 2 1 et a D,F,a 3 1. Les éléments de ces ensembles sont respectvement a D,F,a 2 1 = {a 12, a 19 } et a D,F,a 3 1 ={a 19 }. Concernant l ensemble a D,T 1, on en trouve un seul élément a D,T,a 2 1 ={a 12 }. Par rapport à ces 78

95 4.4. Les algorthmes pour la producton des fragments coopérants Les messages de contrôles envoyés au procédé qu nclut a2 <a2, exec> a w <a2, skp> a w a 1 a w a w <a3, skp> <a3, exec> Les messages de contrôles envoyés au procédé qu nclut a3 Fg La structuraton des actvtés de connexons concernant les messages de contrôles à envoyer vers les procédés qu exécutent a 2 et a 3 éléments, le fragment qu dot être exécuté après a 1 peut être fourn comme sut : Les condtons de transtons vers a 2 et/ou a 3 peuvent devenr vra ou faux. Donc, ã 1 nclut dans un premer temps les messages de contrôle qu dovent être envoyés aux procédés qu exécutent a 2 et a 3. Les actvtés qu envoent les messages de contrôle sont structurées d une manère concurrente mas exclusvement entre elles. La fgure 4.15 llustre les actvtés de connexon avec le contenu des messages qu elles envoent vers les procédés qu ncluent les actvtés concernées. Les actvtés qu envoent les messages de contrôles skp aux actvtés sont suves par les actvtés qu envoent des messages de skp aux actvtés qu sont sur les chemns prs par l élmnaton des chemns morts. En conséquence, les actvtés de connecton qu envoent des messages de skp aux procédés qu ncluent a 6, a 8, a 9, a 10, a 11, a 17 sont structurées d une manère concurrente après l actvté de connexon qu envoe le message skp à a 3. De même, les actvtés de connexons qu envoent les messages de skp aux procédés qu ncluent a 4, a 5, a 7 sont structurées après l actvté de connexon qu envoe le message skp au procédé qu nclut a 2. Ces partes du fragment sont llustrées dans la fgure Ces actvtés qu permettent l nteracton avec les procédés qu ncluent les actvtés qu sont sur les chemns prs par l élmnaton des chemns morts, sont suves par les actvtés de connexons qu propagent l état des mêmes actvtés vers les procédés qu dovent recevor leurs sortes. La fgure 4.17 llustre la structuraton de ces actvtés après les actvtés de connexons. Celles-c sont notamment les éléments de a D,F,a 2 1 et a D,F,a 3 1. La fgure 4.18 llustre le dernère élément des nteractons concernant les messages de contrôle. La dernère actvté de connexon qu on peut ajouter au fragment concernant ã 1, est notamment l exécuton de l actvté a 2 comme a 1 est la premère actvté qu succède à a 2 et peut élmner le chemn qu la pr. Le fragment ã 1 fnt par une actvté de termnason qu caractérse la fn des actvtés de connexon assocées avec a 1. Cette actvté de termnason est une actvté ntermédare que nous utlsons pour connecter le fragment produt aux autres fragments qu correspondent aux actvtés succesves. L exemple c-dessus présente les actvtés qu dovent être exécutées pour connecter une actvté de la spécfcaton centralsée avec les actvtés qu seront dépantes après son exécuton. 79

96 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut a w a w <a, skp> pour tout a de {a 3, a 6, a 8, a 9, a 10, a 11, a 17 } <a2, exec> a w a w a w <a2, skp> a w a w a w a w a 1 a w a w a w a w <a3, skp> a w <a3, exec> <a, skp> pour tout a de {a 4, a 5, a 7 } Fg La structuraton des actvtés de connexons concernant les messages de contrôles pour satsfare l élmnaton des chemns morts Le message <a9, skp, d6, a19> envoyé au procédé qu exécute l actvté a19 a w a w a w a w a w a w a w a w a w a w Le message <a4, skp, d3, a19> envoyé au procédé qu exécute l actvté a19 a 1 a w a w a w a w a w a w a w Le message <a2, skp, d2, a12> envoyé au procédé qu exécute l actvté a12 Fg La structuraton des actvtés de connexons concernant les messages de contrôles pour nformer les procédés qu sont susceptbles d exécuter des actvtés de connexons pour recevor des données envoyées par les autres procédés 80

97 4.4. Les algorthmes pour la producton des fragments coopérants a w a w a w a w a w a w a w a w a w a w a 1 a w a w a w a w a w a w a w a w Le message de contrôle <a 2, exec, d 2, a 12> envoyé au procédé qu exécute a 12 Fg La structuraton des actvtés de connexons concernant les messages de contrôles pour nformer les procédés qu ncluent les actvtés qu dovent utlser les sortes des actvtés que l élmnaton des chemns morts n nfluence pas L exemple llustre une exécuton de l algorthme 1 pour l actvté a 1. Dans la secton suvant, nous présentons l algorthme qu permet la connexon d une actvté avec celles qu la précèdent dans la spécfcaton centralsée Interconnexon avec les actvtés de preset et de preset étue Avant d exécuter une actvté a, un procédé dot être nformé a propos de la termnason des actvtés qu la précèdent dans la spécfcaton centralsée. Les entrées de l actvté à exécuter dovent être reçues également des actvtés qu les fournssent. Il est à noter qu une actvté peut être suspue s elle est prse par un DPE. L élmnaton d un chemn mort nécesste la suspenson de l actvté a et gnore la récepton des messages qu fournssent ses entrées. L algorthme 2 détalle la structuraton des actvtés de connexon qu permettent la récepton des messages de contrôle et de données concernant l exécuton des actvtés. Informellement nous pouvons explquer l algorthme 2 comme sut. La sorte de l algorthme est le fragment a qu précède l exécuton de l actvté a dans son procédé coopérant. Comme nous l avons fat pour la structuraton des actvtés de connexon de postset, ce fragment est composé d autres fragments. Le fragment a T nclut les actvtés de connexon qu reçovent des messages de contrôle des procédés qu exécutent les actvtés de preset de l actvté a. Elles sont structurées d une manère concurrente, car la récepton de tous les messages de contrôle est nécessare pour l exécuton de a. S l actvté est sur un chemn qu peut être prs par un DPE elle peut être suspue par un message venant d un procédé qu peut lancer le DPE. Le fragment a F est composé des actvtés de connexon qu reçovent les messages de suspenson des procédés qu exécutent les actvtés à partr desquelles un DPE qu pr a peut être lancé. Il est à noter que les éléments de a F sont structurés exclusvement pusq une actvté ne peut pas être prse pas pluseurs DPE. S l actvté est exécutée, parce qu elle n est pas prse par un DPE et toutes les actvtés qu la précèdent sont exécutées, ses entrées de l actvté ont été reçues. Cette dernère consdératon est valable seulement pour les actvtés sources de dépances de 81

98 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Input : La spécfcaton centralsée de la composton Output: a A, a forall s S do forall a A s do c forall a j a a j a do s j = servce(a j ); a T a r (s j, < a, exec >) forall a j a F do s j = servce(a j ); a F a r (s j, < a, skp >) a a T a F forall a k a D,F,a j d où a j a a j a do s k = servce(a k ); s j = servce(a j ); a D,T,a j a r (s k, < a, exec, d, a j >) + a r (s j, < a, d, a j >) forall a k a F j do s k = servce(a k ); a D,F,a j a r (s k, < a, skp, d, a j >) a D a D,T,a j a D,F,a j d forall a j a a j a do s j = servce(a j ); a D,T a r (s j, < a, d, a j >) a a D a a D,T Algorthm 2: Interconnexon avec les actvtés de preset et de preset étue données entrantes qu sont exécutées. Pour ce fare, l algorthme produt un fragment, nommé a D,F, qu nclut les fragments exclusfs pour chaque actvté source qu est susceptbles de ne pas être exécutée. Ces éléments sont nommés a D,T,a j et a D,T,a j respectvement. Ces fragments sont produts pour chaque actvté source qu fat parte du preset étu, et, qu est susceptble d être suspue. Le fragment a D,T,a j content deux actvtés de connexon séquentelles pour recevor respectvement le message de contrôle d exécuton de l actvté source et la donnée échangée. Le fragment a D,F,a j content des actvtés de connexon qu reçovent les messages de suspenson exclusvement pour la même actvté source. Le derner fragment à exécuter consste en actvtés de connexons qu reçovent les données venant des procédés qu exécutent les actvtés sources 82

99 4.4. Les algorthmes pour la producton des fragments coopérants des dépances de données entrantes. Ce fragment est nommé a D,T. La dfférence entre les a D,T actvtés de ce procédé et les deux autres est que les actvtés de connexons de reçovent des données venant de procédés qu exécutent les actvtés sources des dépances de données entrantes qu ne sont pas sur un chemn qu peut être prs par le DPE. Nous utlsons l exemple suvant pour décrre des exécutons de l algorthme pour des actvtés dfférentes. Exemple 12 (Interconnexon avec les actvtés de preset et de preset étu) Nous consdérons l exemple de motvaton llustré dans la fgure 5.3. Nous utlsons deux exemples. D abord nous prenons l actvté a 9 pour détaller sa structuraton avec les actvtés de connexons dans un fragment. Les ensembles de preset et postset sont respectvement a 9 = {a 8 } et a 9 = {a 17, a 19 }. L actvté a 9 n a pas de dépances de données entrantes. Par conséquent, a D,F 9 = et a D,T 9 =. Le chemn de contrôle de l actvté a 9 peut être prs par deux DPE dfférents lancés sot à partr de l actvté a 1 ou a 6. Ces actvtés sont les éléments de l ensemble a F 9 = {a 1, a 6 }. Ans, un message de contrôle < a 9, skp > venant du fragment de l actvté a 1 ou a 6 peut suspre l exécuton de a 9 dans son procédé. Pour que l actvté pusse être exécutée dans le procédé qu l nclut, l faut que le procédé qu nclut a 8 envoe un message < a 9, exec > s aucun DPE qu la pr n est lancé. En conséquence, ces tros messages peuvent être reçus exclusvement. La fgure 4.19 llustre la structuraton des actvtés de connexon qu précèdent a 9 dans son procédé. Le message <a 9, skp> reçu du procédé qu exécute l actvté a 1 Le message <a 9, skp> reçu du procédé qu exécute l actvté a 6 a r a r a r a 9 Le message <a 9, exec> reçu du procédé qu exécute l actvté a 6 Fg La structuraton des actvtés de connexons concernant la récepton des messages de contrôles pour la suspenson ou l actvaton de l actvté a 9 Comme l exécuton de l actvté a 9 ne requert pas la récepton d une sorte venant d autres 83

100 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut a r a r a r a 9 Fg La structuraton des actvtés de la fgure4.19 par rapport à l actvé termnale du fragment ã 9 procédés, la récepton du message de contrôle venant du procédé de l actvté a 8 est suve par l exécuton de l actvté a 9 elle-même. Pourtant, la récepton des messages de suspenson ne sont pas suvs par l exécuton de l actvté a 9. Les actvtés de connexon de ces messages sont suves par l actvté termnale du postset de a 8. Ans, la suspenson de l actvté est suve par le début des autres actvtés conversatonnelles qu appartennent au même procédé. Il est à noter que la structuraton des actvtés de connexon qu reçovent les messages de suspenson est exclusve. Le deuxème exemple d actvté est l actvté a 19 qu a pluseurs dépances entrantes. Le preset de l actvté a 19 est a 19 = {a 4, a 9, a 12, a 13, a 18 }. Le fragment qu correspond à l exécuton des actvtés de connexons de l actvté a 19 est a 19. Ce fragment commence avec la récepton du message de contrôle venant du procédé qu nclut l actvté a 8. Concernant les éléments de son preset étu, l actvté a 19 n est pas sur un chemn qu peut être prs par un DPE. En conséquence, l ensemble a F 19 =. Les actvtés sources des dépances de données entrantes peuvent être prses par pluseurs DPE. Les actvtés à partr desquelles un DPE peut être lancé sont les sous-ensembles des ensembles a D,F 19 et a D,T 19. Les actvtés a 12 et a 13 ne sont pas sur les chemns qu peuvent être prs par un DPE. Les ensembles a D,F,12 19 et a D,F,13 19 sont vdes. Pour cela, le procédé qu exécute a 19 ne dot pas tester l état d exécuton de ces actvtés avant d exécuter les actvtés de connexons qu reçovent leur sortes. Au contrare, les actvtés a 4 et a 9 de preset qu fournssent des sortes qu seront utlsées comme les entrées de a 19 dovent être consdérées. L actvté a 4 peut être suspue par deux DPE dfférents qu peuvent être lancés par deux dfférents ponts qu sont a 1 et a 2 respectvement. Ans, a D,F,a 4 19 = {a 1, a 2 }. De même, le chemn de l actvté a 9 peut être prs par un DPE lancé par les procédés qu nclut les actvtés a 1 et a 6. Ans, a D,F,a 9 19 = {a 1, a 6 }. Les actvtés de connexon qu correspondent à la récepton des messages de suspenson venant des procédés qu ncluent ces actvtés sont structurées exclusvement. La fgure 4.21 llustre la structuraton des actvtés de connexon qu reçovent les messages de contrôle pour tester l état d exécuton des actvtés sources des dépances de données entrantes. En outre, cette fgure llustre le message de contrôle venant du procédé de l actvté a 8. Les dernères actvtés de OR-splt qu précèdent les actvtés sources des dépances de données, et, à parte desquelles un DPE qu pr l actvté source n est pas lancé, sont groupées dans a D,T 19. Ce derner est composé de deux ensembles ad,t,a 4 19 et a D,T,a 9 19 où a D,T,a 4 19 = {a 2 } et a D,T,a 9 19 ={a 6 }. S les procédés de ces actvtés nforment le procédé de l actvté a 19 à propos de l exécuton des actvtés sources, les actvtés de connexons qu reçovent les données de procédé peuvent être exécutées. Il est à noter que les actvtés de connexons qu reçovent les sortes 84

101 4.4. Les algorthmes pour la producton des fragments coopérants Le message <a 9, skp, d 6, a 19> reçu du procédé qu exécute l actvté a 6 a r Le message <a 9, skp, d 6, a 19> reçu du procédé qu exécute l actvté a 1 Le message <a 19, exec> envoyé au procédé qu exécute l actvté a 18 a r a 19 a r a r a r Le message <a 4, skp, d 3,a 19> reçu du procédé qu exécute l actvté a 2 Le message <a 4, skp, d 3,a 19> reçu du procédé qu exécute l actvté a 1 Fg La structuraton des actvtés de connexon qu reçovent les messages de suspensons des actvtés sources des dépances de données de l actvté a 19 des actvtés a 12 et a 13 ne nécesstent pas d un test de l état d exécuton des actvtés sources comme celles-c ne sont pas sur les chemns qu peuvent être prs par le DPE. L actvté a 19 a une seule actvté qu la précède avec une dépance de contrôle. Pour que l actvté a 19 pusse être exécutée dans son procédé, le procédé de l actvté a 18 dot envoyer un message de contrôle pour l nformer de la termnason de l actvté a 18. La fgure 4.22 llustre la structuraton de l actvté de connexon qu concerne la récepton du message de contrôle venant du procédé de l actvté a 18. Implémentaton de la termnason correcte Les algorthmes que nous avons présentés concernent les 3 cas prncpaux llustrés dans la fgure Nous avons essentellement cherché à empêcher les stuatons de blocage des procédés qu attent des messages de données de la part d actvtés suspues. Le quatrème cas consste à mplémenter la termnason approprée d un procédé coopérant. Le crtère de global soundness, spécfe qu un procédé ne dot pas contenr de données dans ses canaux de communcaton quand son actvté fnale est exécutée. Cec est appelé la termnason correcte. Pour mplémenter ce prncpe, chaque procédé dot recevor un ou des messages en vue de vder les données restantes des canaux de communcaton. Par rapport aux stuatons de blocages qu empêchent l exécuton décentralsée de la composton, les données stockées dans les channels de communcaton sont mons graves. Une désavantage de telles données qu restent dans les channels est certanement l augmentaton de l espace consommé pour l nstance du procédé. Intutvement, l est souhatable que l espace consommé ne sot pas mportant par rapport à la quantté totale d espace dsponble. Nous consdérons deux stratéges pour gérer les données qu 85

102 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut Le message <a 9, exec, d 6, a 19> reçu du procédé qu exécute l actvté a 6 Le message de donnée reçu du procédé qu exécute l actvté a 9 Le message de donnée reçu du procédé qu exécute l actvté a 13 a r a r a r a r a r a r a r a r a r a r a 19 Le message de donnée reçu du procédé qu exécute l actvté a 12 Le message de donnée reçu du procédé qu exécute l actvté a 4 a r Le message de contrôle <a 4, exec, d 3, a 19> reçu du procédé qu exécute l actvté a 2 Fg La structuraton des actvtés de connexon qu reçovent les messages d exécuton pour les actvtés sources des dépances de données de l actvté a 19 et les actvtés de connexon qu reçovent les données de procédés des actvtés a 12 et a 13 86

103 4.5. Synthèse ne seront pas consommées : 1. L annulaton (vdange des canaux) des données envoyées et non consommées pant l exécuton du procédé dynamquement au moment de la suspenson de l actvté source, 2. L annulaton des données envoyées et non consommées à la fn de l exécuton globale explctement par un message de termnason, Nous avons supposé que la lecture à partr des canaux de communcaton est arbtrare. Cela sgnfe que la présence d une donnée dans un canal n empêche pas la lecture d une autre donnée qu est ajoutée plus tard. La premère méthode de geston des données restant dans les canaux est certanement effcace mas n empêche pas l exécuton correcte globalement. La deuxème méthode est mons effcace d un pont de vue de performance comme les données sont dans les canaux jusqu à la fn de l nstance. Cette dernère nécesste un procédé, et auss un servce qu l exécute, pour envoyer les messages de termnason à tous les procédés coopérants. S on consdère des restrctons du flux d nformaton, les nteractons pour la termnason des procédés dovent être cohérentes avec ces restrctons. Une deuxème mplémentaton possble de la termnason explcte peut être ndépante d un procédé ters. L mplémentaton de la premère méthodologe de termnason est relatvement complquée. Elle consste à spécfer un procédé coopérant avec des actvtés de connexons qu envoent des messages de contrôles aux procédés coopérants concernés pour annuler les données qu ne seront pas consommées. Plus précsément, l faut défnr une autre type de dépance qu caractérsera l annulaton d une donnée après l exécuton d une autre actvté qu sera la source de cette nouvelle dépance. Celle-c peut être une actvté qu est exécutée après la suspenson de l actvté cble de la dépance de donnée. La modalté que nous avons mplémentée est la deuxème. Les rasons de ce chox sont multples. Notre but ultme état de fournr un méthodologe pour les servces pussent établr des nteractons P2P, et cec, avec une cohérence dans laquelle la sémantque est préservée. L utlsaton performante des canaux de communcaton ne fat pas la problématque de notre traval. Cec est valable auss pour la proposton des méthodologes pour la geston effcace de l espace dsponble. En conséquence, chaque procédé coopérant a une actvté de type read qu est placée avant l actvté termnale. Le procédé coopérant qu exécute la dernère actvté de la spécfcaton centralsée a une actvté de connexon de type wrte qu envoe un message de contrôle qu sera reçu par les actvtés de connexon des autres procédés coopérants. Les nstances des procédés coopérants sont enlevées par les servces quand ce message de contrôle est reçu. La consommaton de mémore assocée aux canaux est proportonnelle aux nstances des procédés coopérants actfs. 4.5 Synthèse Dans cette secton, nous résumons les contrbutons de ce chaptre et notre postonnement par rapport aux travaux exstants. Nous résumons également l ntérêt d une telle contrbuton. Au cours de ce chaptre, nous avons proposé une approche générale pour construre les procédés coopérants qu mettent en œuvre une exécuton décentralsée d un procédé workflow centralsé qu spécfe la coordnaton d un ensemble de servce. Le but d une telle approche est d établr des nteractons d égal-à-égal entre les servces composés tout en respectant la sémantque de la spécfcaton centralsée. Dans un contexte workflow, l approche nécesste d une part une spécfcaton centralsée du procédé et d autre part un ensemble de proprétés de communcaton sous-jacentes lés à l envronnement d exécuton des procédés. Étant conscent de ces restrctons, nous avons précsé un ensemble d hypothèses nécessares avant d mplémenter les 87

104 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut structures de données et les algorthmes qu permettent la producton des procédés coopérants. Essentellement, nous avons consdéré les procédés structurés afn de dmnuer la complexté de tratement des algorthmes. Cec est une hypothèse rasonnable qu ne dmnue pas seulement la complexté du tratement mas auss faclte la compréhenson des structures de données utlsées. Une autre consdératon mportante a porté sur un ensemble de modalté de communcaton qu nécesste une confguraton dans un système de geston de procédé. Les modaltés que nous avons choses sont basées sur les prncpes ben connus des procédés coopérants qu sont actuellement mplémentés dans la plupart des systèmes de geston de procédés. La consdératon des modaltés de communcaton, et notamment, les crtères d exacttude, permet de fare des vérfcatons formelles sur les structures de données et les algorthmes proposés. La modélsaton que nous avons adoptée ne nécesste pas une connassance partculère à part des paradgmes caractérstque de l approche workflow qu on peut trouver dans de nombreuses travaux lés et outls exstants. Les qualtés reconnues des paradgmes sont la smplcté des concepts et la grande lsblté des résultats, grâce à l utlsaton de graphsmes et à large une large documentaton. Il faut également soulgner la démarche ndute par ces méthodes qu permet la dstncton de dfférents nveaux d abstracton tels que le flux de contrôle et le flux de données. Nous avons chos un rasonnement ndépant d une spécfcaton concrète telle que WS-BPEL pour être le plus générque possble. Celle-c est une dfférence prncpale de notre contrbuton par rapport à d autres travaux tels que [Bares et al.2007] [Nanda et al.2004] [Khalaf and Leymann2006]. Contrarement aux travaux smlares, nous ne nous contentons pas d une présentaton ntutve d une technque de décentralsaton d une spécfcaton centralsée tels que [Atlur et al.2001] [Sadq et al.2006] [Bares et al.2007]. En partant de cas de fgures smples, nous avons proposé une méthode générque qu peut trater tous type de spécfcatons qu respectent nos hypothèses. Il est à noter que notre proposton vse la décentralsaton des procédés qu spécfent la composton de servces. La partton des programmes mpératfs ou des graphes est assez lon de nos préoccupatons même s on peut rencontrer l utlsaton des termes smlares. Nous tratons ensemble les flux de contrôle, de données et les aspects conversatonnels tout en respectant leur relatons. Cette approche est extensble aux autres aspects qu ne sont pas étudés dans le cadre de cette thèse. Un de ces aspects, peut être le plus populare, est la geston transactonnelle ou la geston des exceptons du procédé qu spécfe une composton. Il consste à spécfer un autre type de flux smlare à celu du contrôle en consdérant les dépances des actvtés qu dovent être suspues ou reprses en cas d échec d une actvté dépante [Yang and Lu2006] [Curbera et al.2003]. Le flux transactonnel spécfe un autre type de dépance, et naturellement, un autre type de message et une autre méthode de structuraton des actvtés de connexon s l est décentralsé. Par conséquent, l nous semble que notre approche peut être étue pour formalser d autre cas smlare en suvant la même approche de producton de procédés coopérants. Rappelons cepant que notre objectf n est pas de défnr un méta-méthode ntégrant toutes les caractérstques d un procédé ou d une composton, mas plutôt de fournr une base qu on peut adapter faclement à des besons dvers. Avec notre approche, chaque dépance est tratée pour être mplémentée comme une nteracton égal-à-égal entre les servces correspondants. Une des crtques que l on peut lu fare est sans doute sa trop grande nature décentralsée. En effet une exécuton complètement décentralsée d un procédé n est pas toujours souhatable. Cet aspect est mentonné dans le chaptre problématque et va être détallé dans le chaptre suvant sous la forme d mplémentaton de poltques de flux d nformaton. En vertu des besons pour la décentralsaton qu sont défns précédemment, et, l acceptaton des standards de procédé basés sur XML, l exécuton décentralsée d une composton peut être 88

105 4.5. Synthèse fasable en mplémentant des paradgmes de la moblté (ou de l échangablté) [Yldz and Godart2007f] [Yldz and Godart2007a] des fragments qu correspondent à l exécuton décentralsée de la spécfcaton centralsée entre les servces composés. Les contrbutons de ce chaptre montrent comment les procédés coopérants, qu consttuent la problématque essentelle de cette approche, peuvent être produts et exécutés. 89

106 Chaptre 4. La modélsaton d un procédé et sa décentralsaton par défaut 90

107 Chaptre 5 Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Sommare 5.1 Introducton Contrôle du flux d nformaton Vue d ensemble et présentaton ntutve de la démarche adoptée Représentatons formelles Poltques du flux d nformaton d un servce Poltques du flux d nformaton d un concepteur Poltques du flux d nformaton contextuelles Tratement des poltques du flux d nformaton Vérfcaton des poltques Établssement des chemns fables entre les servces Producton des procédés coopérants Valdaton de la producton des procédés coopérants Synthèse Introducton Le paradgme de décentralsaton est structuré autour de l établssement des nteractons d égal-à-égal entre les servces composés d un procédé. L une des tâches essentelles d un système de décentralsaton est de modélser, de structurer et de contrôler les restrctons qu gouvernent ces nteractons. Par nature, ces restrctons sont souvent complexes : complexes par leurs structures (une restrcton peut être défne comme étant composée d autres restrctons statques ou dynamques) mas auss par leur valdté (une restrcton peut appartenr à un servce ou être défne par le concepteur d une composton à décentralser). Elles sont également de granularté très varable, allant de la restrcton d une smple nteracton à la spécfcaton d un chemn sophstqué qu une donnée dot suvre à travers les servces. De plus, elles sont fortement nterrelées. Les nteractons peuvent être ssues des dépances de la spécfcaton de la composton ans que des besons du contexte de composton. Dans le chaptre précédent, nous avons détallé comment les nteractons peuvent être étables par rapport à la spécfcaton de la composton sans tenr compte de restrctons partculères. 91

108 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Dans ce chaptre, nous présentons nos contrbutons d adaptaton de notre approche pour la prse en compte des restrctons partculères pour le contrôle du flux d nformaton. Le contrôle du flux d nformaton, qu est largement détallé dans les sectons suvantes, ntègre pluseurs ponts de vue concernant les restrctons et les dfférents types de crtères présents dans le contexte d une composton. Les contrbutons présentées dans le chaptre précédent et celles qu seront présentées dans ce chaptre ne sont pas ndépantes. Elles montrent comment la moblté d un procédé peut être employée pour fournr des exécutons décentralsées en permettant de renforcer le volet applcatf d une composton où les restrctons jouent un rôle mportant. Le reste de ce chaptre est organsé de la manère suvante. Dans la prochane secton, nous présentons le contrôle du flux d nformaton dans sa généralté ; le contrôle du flux d nformaton dans les systèmes orentés objet et sa relaton avec les applcatons nter-organsatonnelles. Par la sute, nous donnons une vue d ensemble de notre démarche pour contrôler le flux d nformaton dans les procédés nter-organsatonnels selon l approche présentée dans le chaptre précédent. Cette secton est suve par des consdératons plus formelles sur le flux d nformaton et les algorthmes correspondants y sont présentés. Les résultats obtenus dans cette secton sont utlsés pour concevor des procédés coopérants qu mplémentent les restrctons consdérées. 5.2 Contrôle du flux d nformaton Le contrôle du flux d nformaton est un aspect ncontournable des compostons effcaces où les servces composés ont des nteractons restrentes par les poltques de sécurté, d ntmté ou de confance. Dans ce chaptre, nous nous ntéressons à la modélsaton et au contrôle du flux d nformaton dans les procédés méters basés sur la composton des servces. Nous présentons une soluton qu sut l approche de geston décentralsée de procédé comme présentée dans le chaptre précèdent. Notre soluton s appue sur des technques de décomposton d une spécfcaton de composton centralsée en un ensemble de procédés méters coopérants qu établssent des nteractons de servces tout en respectant les restrctons du flux d nformaton. Le contrôle du flux d nformaton consste à spécfer et à confgurer les nteractons d un ensemble de composants logcels en consdérant la propagaton de l nformaton dans une composton qu les utlse. Hstorquement, le terme flux d nformaton est apparu dans le domane des langages orentées objets [Myers and Lskov1997]. Dans son contexte orgnal, le contrôle de flux d nformaton a pour objectf d analyser les dépances entre classes concernant la propagaton de l nformaton à travers celles-c. Même s les contrbutons dans ce contexte orgnal restent élémentares par rapport au contrôle du flux d nformaton dans un contexte nter-organsatonnel, elles y sont utles. Les problèmes lés au contrôle du flux d nformaton dans une composton de servce nécesstent la compréhenson et l ntégraton d aspects qu sont souvent étudés séparément comme le contrôle d accès [Mecella et al.2006], la geston de la confance [Malk and Bouguettaya2007] ou la vérfcaton d une descrpton de chorégraphe [Kazhamakn and Pstore2006]. Le contrôle d accès s ntéresse à l accès à l nformaton du pont de vue du servce mas l n amène aucune restrcton à la propagaton de l nformaton dans la composton après un accès. Une descrpton de chorégraphe est effcace pour vérfer la cohérence syntaxque des nteractons d égal-à-égal (P2P) de servces mas elle ne fournt aucun support pour la confguraton des nteractons avancées. Les exemples ncluent l établssement d nteractons P2P pour certanes nteractons et exécuter d autres nteractons par un coordnateur centralsé pour la survellance. Il est clar qu un envronnement de composton peut devenr chaotque face à l augmentaton du nombre du types de restrctons. Comme nous l avons soulgné dans les chaptres précédents (vor le chaptre 2, secton 2.3.1), 92

109 5.3. Vue d ensemble et présentaton ntutve de la démarche adoptée les restrctons qu peuvent co-exster dans un contexte de composton sont multples. Elles sont souvent engrées par les poltques des organsatons qu mplémentent les servces composés. Ces poltques peuvent être entre autres, les drots d accès, les relatons de confance, les relatons d ntmté. En outre, les dfférents concepteurs peuvent défnr les restrctons pour exprmer leur poltques dversfées. Par exemple, un concepteur peut souhater soler deux organsatons partenares dans le cadre d une collaboraton nter-organsatonnelle, et l est sans doute mportant de consdérer ce type de restrctons. Dans un modèle de composton tradtonnel, une mplémentaton cohérente qu peut satsfare l ensemble des poltques n est pas possble. En consdérant les approches prncpales de composton de servces, orchestraton et chorégraphe, à ce stade de la réflexon, aucune soluton alternatve n émerge. Car dans une composton orentée orchestraton, les servces sont solés les uns des autres et l est dffcle d établr des nteractons mutuelles entre eux pour satsfare de telles restrctons. Dans une composton orentée chorégraphe dans laquelle les servces établssent des nteractons ndépamment d une entté centralsée, les nteractons mutuelles peuvent subr des restrctons comme par exemple l empêchement d nteracton mutuelle entre deux servces partculères. De même, les relatons de confance sont s nombreuses qu elles ne peuvent pas être gérées par une seule entté. Par exemple, un servce A peut être évoqué par un servce B même s la sorte de A dot être utlsée par un servce C et B peut router la sorte de A vers C qu ne peut pas évoquer A drectement. Dans ce cas, les relatons de confance des servces dovent être tratées pour tester la valdté des chemns entre les servces. Nous pouvons multpler les exemples de motvaton pour explquer la propagaton de l nformaton dans une composton. Le flux d nformaton contrôlé peut être ssu des relatons entre les servces et de leur beson d ntmté et de sécurté. Par alleurs, la spécfcaton du flux d nformaton peut être une chorégraphe sophstquée pour laquelle le concepteur cherche des servces qu la respectent. On peut auss vor le contrôle du flux d nformaton d une composton comme un moyen pour exploter les restrctons présentes dans un contexte de composton, et qu peuvent être mutuellement contradctores. 5.3 Vue d ensemble et présentaton ntutve de la démarche adoptée Dans cette secton, nous présentons la vue d ensemble du contrôle du flux d nformaton et nous donnons une descrpton ntutve de notre démarche pour l mplémenter. Dans le chaptre précédent, nous avons démontré comment les dépances de la spécfcaton centralsée sont mplémentées sans prre en compte des restrctons partculères. Nous avons montré comment les aspects lés à la décentralsaton du flux de contrôle et du flux de donnée sont tratés. Mantenant, nous révsons cette approche pour ntégrer des restrctons du flux d nformaton. Cet objectf nécesste une consdératon formelle des restrctons consdérées. En outre, l est nécessare d avor un système de rasonnement pour les trater. La nature de ce derner peut être dfférent par rapport à la spécfcaton et l emplacement des restrctons. Dans la spécfcaton des restrctons des poltques, l aspect crtque que nous cherchons à résoudre concerne la propagaton de l nformaton dans la composton. La propagaton de l nformaton est sans doute un aspect mportant dans un contexte d exécuton décentralsée dans lequel les nteractons des servces sont essentelles. Le formalsme que nous avons chos peut être relé aux concepts de confance [Malk and Bouguettaya2007] [Jøsang et al.2006], de geston des drots d accès [Mecella et al.2006], de drot d accès orentés propos [Bertno2004] et de métas-donnée ajoutée à une nformaton prncpale [Srvastava and Velegraks2007]. Nous ne nous ntéressons pas au contexte dans lequel les restrctons sont défnes, nous sommes essen- 93

110 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace tellement concernés par leur satsfacton dans le cadre de l approche présentée dans le chaptre précèdent. Les algorthmes que nous avons développés transforment les dépances de la spécfcaton centralsée en nteractons égal-à-égal. En partant de ce prncpe, on peut consdérer que chaque dépance est potentellement une nteracton entre les servces sous-jacents évoqués par l actvté source et l actvté cble de la dépance. Par rapport aux restrctons venant du contexte de composton, toute nteracton dot être en adéquaton avec ces dernères. S une nteracton n est pas en adéquaton avec une restrcton ; une possblté est d annuler la restrctons qu empêche l nteracton. La deuxème possblté est de trouver un ensemble d nteractons qu satsfat toutes les restrctons en routant l nformaton à travers les servces dsponbles. Cette approche générale cache dffclement la dffculté du tratement des restrctons et les problèmes d mplémentaton des nteractons correspondantes. Parm les solutons d mplémentaton des nteractons, la producton des procédés coopérants est une nouvelle voe que nous avons exploré. Les questons prncpales de cette approche sont ben sûr multples : Comment les restrctons sont-elles modélsées? Comment les restrctons sont-elles tratées? Comment les nteractons possbles sont mplémentées comme des procédés coopérants? La fgure 5.1 donne une vue d ensemble de la méthodologe adoptée. Concepteur du procédé désgne une spécfcaton de composton chost des servces à composer les poltques du flux d nformaton sont spécfés Permted_Interactons= {} Condtonal_Interactons= {} Dened_Interactons = {} Ordnateur les dépances sont extrates Les dépances sont classées en foncton de leur adéquaton aux poltques défns Tratement des poltques du flux d nformaton Chercher un chemn fable à travers les servces pour remplacer l nteracton [Ou] Le chemn exste [Non] Produre les fragments coopérants qu mplémentent le chemn trouvé Modfer les poltques Fg. 5.1 Vue d ensemble de la méthodologe du contrôle du flux d nformaton 94

111 5.4. Représentatons formelles Le chox de la méthodologe est en parte ntutf : l est le frut d une réflexon en sprale sur la modélsaton et l exécuton des procédés. On peut le justfer en consdérant les éléments suvants : la présence d un nombre mportant de restrctons qu dovent être consdérées dans un procédé nter-organsatonnel et leur dversté, la volonté de défnr certanes restrctons ndépamment d une spécfcaton partculère, la volonté d utlser le même formalsme pour décrre le plus grand nombre d aspects d un procédé afn de smplfer la mse en œuvre du modèle, la possblté d mplémenter des nteractons avancées d une manère systématque au moment de la producton des procédés coopérants. Les restrctons du flux d nformaton sont sensbles au temps et à l espace. Le lecteur peut juger les restrctons présentées c-après comme élémentares par rapport à la défnton des restrctons smlares tels que les drots d accès dans des systèmes de geston de base de données [Josh et al.2005] [Bertno et al.2005] ou dans les systèmes de geston de workflow [Bertno et al.2004] [Mecella et al.2006]. Nous attrons à nouveau l attenton sur le fat que les restrctons que nous avons consdérées ne sont qu un sous-ensemble de restrctons de base qu peuvent être consdérées pour exprmer des restrctons plus sophstquées. En outre, le problème mportant que nous cherchons à résoudre est l mplémentaton d une exécuton décentralsée dans le contexte de telles restrctons. 5.4 Représentatons formelles Dans cette secton, nous présentons quelques consdératons formelles concernant les poltques de flux d nformaton. Comme nous l avons déjà soulgné, ces restrctons peuvent être ssues des dvers éléments mplqués dans la composton. Nous consdérons tros groupes de restrctons. 1. Les poltques du flux d nformaton d un servce, 2. Les poltques du flux d nformaton des concepteurs, 3. Les poltques du flux d nformaton contextuelles (routage). Chaque groupe de restrctons est détallé dans les sous-sectons suvantes. Comme nous allons l argumenter dans la sute de ce chaptre, l n est pas possble de proposer une spécfcaton complète de la modélsaton des restrctons qu peuvent exster dans un contexte nterorgansatonnel rche en termes d aspects de sécurté, de confance, de contrante temporelle etc. Nos consdératons portent sur la modélsaton de restrctons qu peuvent servr comme des constructeurs atomques pour la modélsaton d un grand nombre de restrctons potentelles Poltques du flux d nformaton d un servce Dans cette secton, nous présentons les poltques du flux d nformaton qu un servce peut exposer dans une composton dont l en fat parte. La défnton et l mplémentaton de ces poltques sont smlares aux restrctons de contrôle d accès. Dans le chaptre précédent nous avons vu que les actvtés orgnales d une spécfcaton centralsée sont structurées dans un procédé coopérant qu est exécuté par le servce et que les actvtés de connexon portent les nteractons respectves. Les flux d nformaton qu régularsent les données entrantes et sortantes d un servce dovent, ntutvement, spécfer les poltques sur ces nteractons. Le tableau 5.1 résume les poltques qu un servce peut exposer. Les restrctons de base spécfent les servces qu peuvent fournr les entrées d une opératon et recevor les sortes d une opératon à un 95

112 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace servce. De même que nous avons fat une dstncton entre les données d une opératon et son nvocaton, un autre type de restrcton spécfe les restrctons concernant l nvocaton d une opératon ndépamment de ses données d entrée et de sorte. L nvocaton est fate par les messages de contrôle venant de la part d autres procédés exécutés par d autres servces. Comme un servce peut restrendre les nvocatons entrantes, l peut restrendre les messages de contrôle ems vers les autres servces. Le derner type de poltque de flux d nformaton concerne les messages de suspenson qu consttuent un autre type de message de contrôle. Prédcat Opérandes Les types des opérandes Exemple can_n[d c ] 3 D, OP, S s can_n(n, op, s j ) [d c ] est vrae, l entrée n de l opératon op du servce s peut être fourne au servce s j can_out[d c ] 3 D, OP, S s can_out(out, op, s j ) [d c ] est vrae, la sorte out de l opératon op du servce s peut être fournr au servce s j can_act_from[d c ] 2 OP, S s can_act_from(op, s j ) [d c ] est vrae, l opératon op du servce s peut être évoquée par le servce s j can_act_to[d c ] 2 OP, S s can_act_to(op, s j ) [d c ] est vrae, le message de contrôle ssue de la termnason de l opératon op peut être envoyé au servce s can_abt[d c ] 3 OP, S, S s can_abt(op j, s k, s j ) [d c ] est vrae, l actvté de connexon qu fournt l entrée de l opératon op j qu évoque le servce s k peut être suspue avec le message de contrôle venant du servce s j. Il est à noter que s le servce s k est null, l nvocaton de l opératon op j est suspue selon le message venant du servce s j. 96 Tab. 5.1 Les poltques du flux d nformaton appartenant à un servce Le tableau 5.1 donne une représentaton formelle des poltques du flux d nformaton d n-

113 5.4. Représentatons formelles formaton sous forme de prédcats. Les poltques sont défnes au nveau de l dentté du servce, de l dentté de l opératon et de l dentté de la donnée. Mas elles peuvent être faclement étues à un groupement. Par exemple, une poltque défne pour un servce peut être exprmée de telle sorte qu elle sot valable pour un groupe de servces. Ce type de vson est le même pour les données d un procédé ou un type d opératon. Comme cette consdératon ne change pas le rasonnement dans ses grandes lgnes, nous préférons lmter notre traval aux les denttés des enttés décrtes dans les tableaux de poltques (vor les tableaux 5.1, ). Exemple 13 (Poltque du flux d nformaton d un servce) Cconsdérons l exemple présenté dans le chaptre 2. S nous voulons spécfer les poltques consdérés, nous pouvons utlser les prédcats suvants. Admettons que l opératon de l Inspecteur qu est nvoquée dans le cadre de cette composton sot nommée op ns. Cette opératon a deux données d entrée qu sont nommées : n ns1 et n ns2. Ce servce spécfe que ces données peuvent être fournes de la part du servce Hôptal et du servce Polce. Avec le formalsme que nous avons développé, ces restrctons sont spécfées comme : can_n(n ns1, op ns, Hôptal), can_n(n ns2, op ns, Hôptal), can_n(n ns1, op ns, Polce), can_n(n ns2, op ns, Polce). Nous pouvons également magner la défnton d attrbuts condtonnels pour ces restrctons. Un attrbut est la valeur de la donnée échangée. Admettons que le rapport venant du servce Hôptal pusse être accepté s l appartent au clent Dupont. Ans cette condton peut être spécfée par un attrbut ns2.owner==dupont dans un prédcat comme can_n(n ns1, op ns, Hôptal)[ns1.owner==Dupont] Poltques du flux d nformaton d un concepteur Le concepteur d un procédé qu compose un ensemble de servces peut défnr la spécfcaton de pluseurs manères. Les spécfcatons de composton que nous utlsons pour dérver les procédés coopérants exprment les dépances de contrôle et de données des appels aux servces. Un grand nombre de travaux récents portent sur la défnton automatque de ces spécfcatons en tratant les dépances des servces atomques [Berard et al.2005] [Betn-Can et al.2005] [Fu et al.2005] [Fu et al.2005] [Bultan et al.2006]. Sans rentrer dans les détals de ces travaux, on peut les résumer comme sut. Analyser les dépances de composants autonomes consste à calculer des combnasons par des analyses formelles de model chekng [Marcon et al.2006] ou de theorem prover [Rao et al.2006]. Comme dans les systèmes de vérfcatons tradtonnels, l dée de base est de défnr une confguraton but et d essayer de calculer les nteractons des composants de telle sorte que la confguraton but sot attente. Cette dernère peut prre la forme d une planfcaton comme dans les systèmes de rasonnements d ntellgence artfcelle [Pstore et al.2005] ou de calcul de chemns dans un graphe [Dahl et al.]. Il est à noter que des analyses formelles smlares peuvent être utlsées pour vérfer les caractérstques secondares des spécfcatons de composton telle que la cohérence transactonnelle [Rusnkewcz and Georgakopoulos1994]. Un concepteur peut également défnr des poltques du flux d nformaton. Les motvatons sont nombreuses. Une motvaton essentelle est le contexte organsatonnel dans lequel un concepteur peut voulor soler des servces les uns des autres ou ben les fare nteragr par rapport à un ensemble de restrctons. Le tableau 5.2 résume les poltques qu un concepteur peut mplémenter dans une composton. Comme nous l avons mentonné c-dessus, la plus smple de ces restrctons est celle qu spécfe la possblté d nteracton entre deux servces. Par la sute, les autres restrctons spécfent les nteractons qu concernent l nvocaton d une opératon et les données entrantes et sortantes d une opératon. Ces restrctons sont smlares aux restrctons défnes par un servce et peuvent être éventuellement contradctores avec ces dernères. Une restrcton porte sur l mplcaton d un ters servce dans une nteracton entre deux servces. Un 97

114 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace concepteur peut voulor s nformer ou ben nformer un autre servce à propos de l nteracton de deux servces. C est souvent le cas des compostons orentées chorégraphe dans lesquelles les servces nteragssent les uns avec les autres d une manère décentralsée. Prédcat Opérandes Les types des opérandes Exemple can_see 2 S, S s can_see(s, s j ) est vrae, les servces s et s j peuvent avor des nteractons drectes must_n[d c ] 4 OP, D, S, S s must_n(op, n, s, s j ) [d c ] est vrae, l entrée n de l opératon op du servce s dot être fourne par le servce s j must_out[d c ] 4 OP, D, S, S s must_out(op, out, s, s j ) [d c ] est vrae, la sorte out de l opératon op du servce s dot être fourne au servce s j must_act_from[d c ] 3 OP, S, S s must_act_from(op j, s j, s ) [d c ] est vrae, l opératon op j du servce s j dot être évoquée par le servce s must_nv_to[d c ] 3 OP, S, S s must_nv_to(op, s, s j ) [d c ] est vrae, le message de contrôle ssu de la termnason de l opératon op du servce s dot être envoyé au servce s j must_copy[d c ] 5 OP, D, D, S, S s must_copy(op, n, out, s, s j ) [d c ] est vrae, les nformatons d actvaton et de termnason de l opératon op du servce s, l entrée n et la sorte out dovent être reçues par le servce s j. Il est à noter que n et/ou out peut être nuls. Tab. 5.2 Descrpton des poltques du flux d nformaton d un concepteur de procédé Les restrctons peuvent être également étues vers la défnton de types de servces, d opératons ou de données comme nous l avons détallé dans la secton précédente. Les servces sont 98

115 5.4. Représentatons formelles toujours consdérés comme des enttés autonomes qu on ne peut pas modfer. Les restrctons d un concepteur, même s elles spécfent les nteractons de servces, peuvent être modfées par le concepteur. Exemple 14 (Poltques du flux d nformaton de concepteur) De nouveau, nous consdérons l exemple de motvaton présenté dans le chaptre 2. Les dépances de la spécfcaton centralsée défnssent les nteractons futures de l exécuton décentralsée. En partant de ces dépances, un concepteur peut dentfer des poltques qu spécfent les nteractons correspondantes. Admettons que le concepteur veulle empêcher l nvocaton du servce Lvrason de la part d un servce ters. Dans la spécfcaton centralsée, l actvté a 4 qu nvoque le servce Inspecteur a une dépance de contrôle avec l actvté a 5 qu nvoque le servce de Lvrason. En outre, la dernère actvté a deux dépances de donnée entrantes. Ces dépances de données ne concernent pas l nvocaton de l actvté. L absence d une poltque du type can_see(inspecteur, Lvrason est suffsant pour empêcher une nteracton de ce type. S cette poltque exste, le concepteur peut utlser une poltque de type must_act_from. Admettons que l opératon du servce Lvrason nvoquée par l actvté a 5 sot op lvrer. S le concepteur ne veut pas que cette opératon sot nvoquée par le servce Inspecteur, l peut spécfer must_act_from(op lvrer, Lvrason, Assurance). Ans, le servce est nvoqué de la part du servce qu aurat été le coordnateur centralsé de l exécuton centralsé. De même, on peut ajouter des attrbuts condtonnels à cette poltque Poltques du flux d nformaton contextuelles Dans cette secton, nous présentons un autre type de restrctons nommées poltques contextuelles ou poltques de routage. Ces poltques peuvent appartenr à la fos aux servces composés et aux concepteurs. Le contrôle du flux d nformaton consste à défnr le chemn qu une donnée dot suvre dans la composton. Ans, une donnée peut être routée à travers les servces tout en respectant les restrctons. Dans ce contexte, l est sans doute mportant de dscuter l adéquaton d un servce pour fare parte d un chemn. Évdemment, l adéquaton d un servce à une l opératon de routage peut être défne par un concepteur, les nformatons contextuelles ou le servce qu fournt la donnée. Les poltques d adéquaton peuvent être défnes en tratant pluseurs types de connassances. Dans un contexte décentralsé, la propagaton de l nformaton est gouvernée par les relatons lées à la sécurté telles que la confance. Notre compréhenson de l adéquaton d un servce par rapport à un autre est la mse en œuvre des relatons de sécurté lées à la crculaton de données entre ceux-c. Un servce peut être consdéré comme adéquate pour une opératon de routage s l respecte les règles confances lées aux exgences de sécurté ou d ntmté. Les poltques du flux d nformaton explctent les règles de sécurté pour décder de l adéquaton d un servce à remplacer une nteracton qu n est pas conforme aux restrctons dans un chemn partculer. Elles se manfestent de tros façons. Le premer type défnt l adéquaton d un servce à la constructon d un chemn va d autres servces. Deux autres poltques permettent la spécfcaton de l adéquaton par rapport à la source et à la destnaton du message routé. Les tros types de restrctons peuvent également contenr des attrbuts condtonnels permettant d exprmer les stuatons condtonnelles sur les données échangées. Il faut tout de même dre que les poltques qu peuvent être consdérées ne caractérsent pas la réalté du contexte à partr duquel elles explctent les crtères de chox de servces pour les opératons de routage. En partculer, l n est pas toujours auss évdent de donner un énoncé ntal d un problème de défnton de ce type de restrctons. D autre part, les restrctons contextuelles présentées peuvent servr comme des restrctons atomques à combner pour l expresson de restrctons 99

116 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace plus sophstquées. Le tableau 5.3 formalse les prncpales restrctons. Prédcat Opérandes Les types des opérandes Exemple can_route[d c ] 2 M, S s can_route(m, s ) [d c ] est vrae, le message m peut être routé à travers le servce s can_route_to[d c ] 3 M, S, S s can_route_to(m, s, s j ) [d c ] est vrae, le servce s peut router le message m au servce s j. Ce poltque caractérse la relaton de confance du servce s pour le servce s j can_route_from[d c ] 3 M, S, S s can_route_from(m, s, s j ) [d c ] est vrae, le servce s j peut router le message m reçu du servce s. Ce poltque caractérse la confance du servce s j pour le servce s Tab. 5.3 Les poltques du flux d nformaton contextuelles Exemple 15 (Poltques du flux d nformaton contextuelles (routage)) Dans l exemple de motvaton du chaptre 2, nous avons dscuté la possblté de routage de la sorte du servce Hôptal vers Inspecteur à travers le servce Polce. À ce pont, l faut certanement défnr l adéquaton du servce Polce. L adéquaton peut être défne par le servce Polce ou par le concepteur. La premère poltque du flux d nformaton contextuelle qu dot exster dans ce scénaro est la poltque can_route(d 1, Polce) qu spécfe l adéquaton de Polce pour le routage de la donnée de procédé. Les deux autres restrctons ne sont pas mportantes pour ce scénaro. Parce que le servce Polce est l unque ntermédare entre Hôptal et Inspecteur. En conséquence, l est mentonné dans les poltques du flux d nformaton exposés des servces. Les deux dernères poltques du flux d nformaton sont approprées pour l expresson des relatons entre pluseurs servces ntermédares. Les attrbuts condtonnels Les poltques du flux d nformaton sont assocées à des attrbuts condtonnels qu spécfent leur valdté. Dans cette secton, nous présentons les attrbuts condtonnels. La spécfcaton de ceux-c est mportante pour la tratement des poltques d une manère statque. Comme nous l avons déjà précsé, les poltques de flux d nformaton sont tratées seulement avant l exécuton. L mplémentaton des attrbuts condtonnels fournt une certane flexblté à la nature statque des restrctons consdérées. Le tableau 5.4 llustre les prédcats condtonnels que nous avons 100

117 5.5. Tratement des poltques du flux d nformaton utlsés pour l expresson des stuatons condtonnelles. Les condtons exprment des contrantes défnes pour les valeurs de données, les denttés des servces et leur états d exécuton possbles. Il est à noter que les poltques sont dentfées par un servce s et les restrctons sont exprmées pour les éléments de ce servce. Prédcat Opérandes Les types des opérandes Exemple <,, =,, > 1 D Ils permettent la spécfcaton des restrctons sur les valeurs des données de procédés nvoked 2 OP, S S nvoked(op, s j ) est vrae, l opératon op du servce s est actvée par le servce s j aborted 2 OP, S S aborted(op, s j ) est vrae, l opératon op du servce s est suspue par le message de contrôle envoyé par le servce s j out 3 D, S, S S out(out, op, s j ) est vrae, la sorte out de l opératon op du servce s est fourne au servce s j n 3 D, S, S S n(n, op, s j ) est vrae, l entrée n de l opératon op du servce s est fourne par le servce s Tab. 5.4 Les attrbuts condtonnels Comme les poltques du flux d nformaton, les attrbuts condtonnels n exprment pas un ensemble mportant des stuatons condtonnelles telles que les stuatons temporelles ou spatales. En outre, la spécfcaton des attrbuts condtonnels peut se fare à un nveau plus dynamque, parce que les assertons portent sur des stuatons qu on peut prédre avant l exécuton. En consdérant ces smples attrbuts condtonnels, notre but est de démontrer l mplémentaton des nteractons des procédés coopérants produts dans des stuatons condtonnelles. 5.5 Tratement des poltques du flux d nformaton Dans cette secton, nous présentons notre approche du tratement des poltques du flux d nformaton présentées dans la secton précédente. Le but ultme du tratement des poltques est de trouver des chemns fables dans la composton à travers les servces composés. Nous soulgnons que notre traval ne porte pas sur la recherche des chemns dans les graphes ou de résoluton des contrantes. Notre but est d ntégrer l mplémentaton des restrctons exstantes dans la producton des procédés coopérants. Cec est certanement lé à la nature des restrctons consdérées ans qu à leur tratement. Nous pouvons llustrer notre chox par un contre-exemple. Supposons que les restrctons du flux d nformaton soent défnes par une seule entté et que la même entté sot mplquée dans l exécuton globale. Grâce à l mplcaton contnue de cette entté dans l exécuton, les restrctons peuvent être défnes comme des règles et un moteur d nférence peut les trater dynamquement. L exemple par excellence pour ce type de rasonnement est 101

118 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace la modélsaton et le rasonnement sur les poltques d accès dans les systèmes de geston de workflow centralsés [Bertno et al.1999]. Un autre exemple où une entté centralsée est employée est le système OSIRIS pour le chox dynamque des servces en foncton de leur dsponbltés [Schuler et al.2004] Vérfcaton des poltques Dans cette sous-secton, nous détallons la vérfcaton des poltques du flux d nformaton comme la premère étape de l établssement des chemn fables entre les servces. Comme nous l avons antéreurement soulgné, chaque dépance de contrôle (E c ), de donnée (E d ), et d étue (E ext ) correspond à une nteracton entre le servce source et le servce cble de la dépance. Dans les grandes lgnes, la vérfcaton porte sur le test d adéquaton entre les dépances et les poltques de flux d nformaton. La vérfcaton des poltques concerne la producton de tros ensembles qu regroupent les dépances du procédé par rapport à leur valdté avec les poltques de flux d nformaton. Les ensembles sont : Dened Interactons, P ermtted Interactons et Condtonal Interactons. Les éléments de Dened Interactons et P ermtted Interactons contennent respectvement les dépances du procédé pour lesquelles une nteracton mutuelle entre les servces sous-jacents est respectvement, mpossble et possble. Les éléments de l ensemble Condtonal Interactons concernent les dépances du procédé qu peuvent être mplémentées comme des nteractons drectes entre les servces pour la parte vrae ou fausse de la condton. En conséquence, une parte de l nteracton est consdérée comme une nteracton permse et l autre parte est consdérée comme une nteracton qu dot être mplémentée par un autre ensemble d nteractons. La vérfcaton ne peut pas se fare par des tests smples. Car, les attrbuts condtonnels nécesstent un tratement orenté planfcaton. Cec est lé à des attrbuts condtonnels qu exprment des restrctons sur l hstore de l exécuton telles que l état d exécuton des actvté. Par rapport aux spécfcatons des stuatons condtonnelles, les nteractons exgées peuvent être nombreuses. Nous formalsons les nteractons condtonnelles dans pluseurs sous-ensembles. Le premer sous-ensemble correspond aux stuatons condtonnelles qu peuvent être mplémentée comme une nteracton drecte entre deux servces. Cette parte de l ensemble est nommée Condtonal Interactons +. Elle content un élément qu caractérse l nteracton possble. Les nteractons qu dovent être remplacées par des chemns fables sont regroupées dans l ensemble Condtonal Interactons. Par rapport au nombre de stuatons condtonnelles, les éléments de l ensemble Condtonal Interactons sont nommés Condtonal Interactons 1... Condtonal Interactons n. Chaque élément Condtonal Interactons de l ensemble Condtonal Interactons est censé être remplacé par un chemn fable. La fgure 5.2 llustre la vue d ensemble du processus de vérfcaton des poltques et les nteractons correspondantes. Dans le processus de vérfcaton, un premer test porte sur la vérfcaton des poltques en vue du groupement des nteractons dans les ensembles P ermtted Interactons et Dened Interactons. Cette vérfcaton est en parte ntutve. Les poltques du flux d nformaton des servces composés et les poltques spécfées par les concepteurs sont au cœur de cette opératon de vérfcaton. Par la sute, les poltques concernant les attrbuts condtonnels sont tratés. Ces poltques peuvent porter sur les stuatons condtonnelles dépant des valeurs des données du procédé ou ben de l hstore d exécuton du procédé. Pour les restrctons qu portent sur les condtons exprmées avec les données du procédé, un regroupement ntal est fat dans les deux ensembles Condtonal Interactons + et Condtonal Interactons. Ensute, la vérfcaton porte sur les éléments des nteractons regroupés dans P ermtted Interactons et Condtonal Interactons +. Car ces deux ensembles contennent les nteractons probables exprmées dans certanes poltques du flux d nformaton. 102

119 5.5. Tratement des poltques du flux d nformaton Le tratement des éléments de ces deux ensembles produt les éléments de Condtonal Interactons. Poltques du flux d'nformaton des servces Poltques duè flux d'nformaton des concepteurs Condtonal_Interactons Pemtted_Interactons Dened_Interactons Attrbuts condtonels Condtonal_Interactons + Condtonal_Interactons - Fg. 5.2 Vue d ensemble du tratement des poltques pour la vérfcaton de l adéquaton des poltques et des nteractons Les aspects formels de la vérfcaton des poltques du flux d nformaton sont llustrés dans les deux algorthmes suvants. L algorthme 3 llustre la vue d ensemble de la vérfcaton applquée à une dépance de donnée. La premère parte de vérfcaton consste à classer les dépances en foncton de leur adéquatons dans tros ensembles. L algorthme est détallé pour une dépance de donnée qu rele deux actvtés. L algorthme peut être applqué à une dépance de contrôle ou à une dépance d étue. Il est à noter que la deuxème parte de l algorthme utlse les résultats de la premère parte en vue d dentfer les nteractons condtonnelles qu dépent des états d nteracton des autres actvtés. Exemple 16 (Vérfcaton des poltques du flux d nformaton) Nous consdérons le procédé llustré en fgure 5.3 et les poltques présentées dans le tableau 5.5 pour explquer la vérfcaton des poltques par rapport au procédé. Les nteractons vérfées concernent les dépances de donnée entre les actvtés a 12 et a 19, et, a 13 et a 19. Nous assumons que les actvtés a 12 et a 13 sont exécutées par le servce Hôptal et l actvté Inspecteur. Par rapport aux poltques du tableau les nteractons de ces servces dovent être remplacées, parce que l nteracton qu correspond à la dépance de donnée d 5 n est pas possble à cause de la poltque du servce Inspecteur qu lmte l entrée n 1 de son opératon op 19 au servce Polce. En conséquence cette nteracton est placée dans l ensemble de Dened Interactons. La deuxème nteracton qu correspond à la dépance d 5, est une nteracton condtonnelle, car la poltque défnt une condton sur 103

120 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Hôptal Inspecteur can_out(out 1 (d 4 ), op 13, Inspecteur) can_n(n 1 (d 4 ), op 19, Polce) can_n(n 2 (d 5 ), op 19, Hôptal)[n 2.att 1 == Dupont ] Tab. 5.5 Exemples de poltques du flux d nformaton must_out(op 2, out 1 (d 2 ), Polce, Assurance) must_n(op 12, n 1 (d 2 ), Lvrason, Hôptal) Tab. 5.6 Exemples de poltques du flux d nformaton la poltque exposée. L échange peut se fare entre Hôptal et Inspecteur s l attrbut att 1 de la donnée échangée est Dupont. Pant l exécuton, cette donnée peut prre cette valeur ou pas. En conséquence, l y a deux possblté. Pour cette valeur de la donnée, l y a deux possbltés d nteracton dont l une est permse. La parte permse de l nteracton est placée dans l ensemble Condtonal Interactons +. L autre parte de l nteracton fat parte de l ensemble Condtonal Interactons. Il est à noter que le concepteur dot supporter ces nteractons en défnssant la poltque can_see(hôptal, Inspecteur). Consdérons mantenant les poltques llustrées dans le tableau 5.6. Ces poltques sont des restrctons défnes par le concepteur de procédé. Elles llustrent les nteractons requses par le concepteur en vue de cette composton. Ces restrctons concernent la sorte de l actvté a 2 et l entrée de l actvté a 12 lée par la dépance de donnée d 2. Nous assumons que l actvté source est exécutée par le servce Polce et l actvté cble est exécutée par le servce Hôptal. La premère poltque du tableau 5.6 spécfe que la sorte de l actvté a 2 qu nvoque op 2 de Polce dot être routé vers le servce Assurrance par le servce Polce. La deuxème poltque spécfe que cette entrée qu dot être utlsée comme l entrée de l opératon op 12 nvoquée par l actvté a 12, dot être reçue par le servce Hôptal depus servce Lvrason. En conséquence, cette dépance est placée dans l ensemble Dened Interactons. Les nteractons qu sont regroupées dans ces ensembles consttuent les entrées du mécansme qu remplace les nteractons non-conformes par des chemns fables et du mécansme qu produt les procédés coopérants correspondants. Les éléments prncpaux que nous tratons sont le modèle de procédé à décentralser sont les dépances de données, les dépances de contrôles et les dépances étues. Chaque dépance est vérfée par rapport aux poltques pour décder de la possblté de son mplémentaton comme une nteracton d égal-à-égal entre les servces sous-jacents. Les poltques sont vérfés en pluseurs étapes. La premère vérfcaton porte sur la vérfcaton des poltques du servce source et celles du servce cble de la dépance. La deuxème vérfcaton porte sur le tratement des poltques des concepteurs. Les poltques des concepteur concernant la possblté des nteractons entre les servces sont vérfées. Les dépances qu sont conformes à la fos aux poltques des servces et auss aux poltques des concepteurs sont placées dans l ensemble P ermtted Interacton. S une dépance n est pas conforme à une poltque, elle est placée dans l ensemble Dened Interacton. Les dépances qu font objets des attrbuts condtonnels sont placées dans l ensemble Condtonal Interactons. Une parte d une dépance peut être en adéquaton avec la poltque alors que le complément ne l est pas. Dans ce cas, la parte fasable peut être mplémentée comme une nteracton drecte entre les servces. La parte qu n est pas en adéquaton dot être tratée comme une dépance qu est dans l ensemble Dened Interacton. Les attrbuts condtonnels qu exprment les condtons sur les données du 104

121 5.5. Tratement des poltques du flux d nformaton Input : 1) A process, P 2) Informaton flow polces of composed servces, I S 3) Informaton flow polces of process desgners, I P D Output: 1) Dened Interactons(P ) 2) Condtonal Interactons(P ) 3) P ermtted Interactons(P ) forall e E d do s = source ser (e) ; s j = target ser (e) ; a = source act (e) ; a j = target act (e) ; op = operaton(a ) où out est la sorte de op ; op j = operaton(a j ) où n j est l entrée de op j ; swtch e do case can_see(s, s j ) can_n(n j, op j, s ) can_out(out, op, s ) P ermtted Interactons(P ) e ; case can_see(s, s j ) can_n(n j, op j, s ) can_out(out, op, s ) Dened Interactons(P ) e ; case (can_see(s, s j )[d a ] can_n(n j, op j, s )[d b ] can_out(out, op, s )[d c ]) (d b d c d b d a d a d c ) Condtonal Interactons(P ) e ; forall e Condtonal Interactons où subt une condton dépante de l hstorque de l exécuton avec d a la condton consdérée do forall e P ermtted Interactons Condtonal Interactons + do f d a est vrae pour l nteracton e then Dened Interactons e P ermtted Interactons e Algorthm 3: La vérfcaton de l adéquaton des poltques et des nteractons pour une dépance de donnée procédé peuvent être vérfés drectement. Les condtons qu exprment l état d exécuton des actvtés exgent la vérfcaton de la possblté d exécuton de l exécuton passée. Les dépances restrentes par les attrbuts condtonnels des autres poltques sont placées dans un ensemble ntermédare pour être vérfées. L ensemble P ermtted Interacton nclut deux sous ensembles nommés P ermtted Interacton + et P ermtted Interacton pour le tratement ntermédare. Auss, les nteractons sont regroupées dans tros ensembles : P ermtted Interactons, Dened Interactons, Condtonal Interactons. Le derner est composé de deux sous-ensembles comme nous l avons llustré dans la fgure

122 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Établssement des chemns fables entre les servces La vérfcaton classe les nteractons en tros groupes. Comme nous l avons soulgné c-dessus, les nteractons qu ne sont pas en adéquaton avec les poltques dovent être remplacées par des nteractons alternatves qu respectent les poltques de chacun des servces composés. Les nteractons alternatves sont des chemns produts à partr des poltques du flux d nformaton. Ces chemns fables sont consttués d nteractons mutuellement en adéquaton. Dans cette secton, nous explquons les prncpes de l établssement des chemns fables et certanes défntons nécessares pour l évoluton des algorthmes qu produsent les procédés coopérants. Comme nous l avons soulgné c-dessus, le problème d mplémentaton des chemns fables est un problème de recherche de chemn par rapport aux poltques du flux d nformaton. Il est à noter que nous ne cherchons pas à mplémenter une nouvelle méthode de recherche de chemn pour ce propos. Pour ce fare, nous avons utlsé l algorthme de Djkstra [Djkstra1959] qu est largement utlsé dans la modélsaton de recherche de chemn dans les systèmes d nformaton. L algorthme de Djkstra consste à trouver le plus court chemn entre deux ponts. En conséquence, les concepts que nous avons utlsés dovent être adaptés pour ces algorthmes consdérés. Ces mesures peuvent être essentellement défnes par les nveaux de confance, le coût d utlsaton du chemn ou ben des crtères smlares que l on peut tradure en valeurs numérques. Dans l mplémentaton du prototype, nous avons utlsé ces deux métrques c-dessus. Nous n étrons pas la dscusson sur ce pont. Parce que cela ne change pas la démarche globale de l approche. Par rapport à l exstence des chemns fables, nous défnssons les concepts suvants. Ils correspondent aux types de chemns défns pour chaque type d nteractons défnes c-dessus. Défnton 1 (Chemn fable) Unchemnfablerp qu remplace une nteracton e E c E d E ext est une sére de servces rp = <s m, s m+2,..., s n 1, s n > où s rp, l y a une adéquaton du flux d nformaton entre s et s +1. S e Dened Interactons alors rp est unque. S e Condtonal Interactons, e j Condtonal Interactons, le chemn rp nclut un sous-chemn rp j. Comme nous l avons présentée dans la défnton 1, un chemn fable est consttué d une sére de servces où les servces sont mutuellement en adéquaton avec le flux d nformaton. Pour les servces qu sont les éléments ntermédares d un chemn, les poltques contextuelles et les poltques des concepteurs sont tratées. Les servces qu sont au début et à la fn d un chemn fable concernent les poltques du flux d nformaton exposées par ces servces et ans que celles de concepteurs de procédé. Les détals de l algorthme Djkstra mplémenté peut être trouvé dans l annexe B. Il est à noter que la problématque prncpale de notre traval ne porte pas sur la proposton d un algorthme de recherche de chemn. Nous avons utlsé un algorthme appropré pour formalser ce problème. Exemple 17 (Détal de l algorthme smplfé) L algorthme 4 résume une parte de la démarche de l algorthme complet détallé dans l annexe B. Il llustre la recherche de chemn pour une nteracton correspondant à une dépance de contrôle et à une dépance de donnée. En effet, les poltques tratées pour la recherche de chemn sont plus nombreuses que celles qu sont présentés dans cet algorthme rédut. 106

123 5.6. Producton des procédés coopérants Entrée : 1) La spécfcaton du procédé, P 2) Les poltques du flux d nformaton, Sorte : 1) FALSE, s un chemn fable n est pas trouvé pour une nteracton 2) Les chemns pour toutes nteractons qu dovent être remplacées, R P = [rp 0,..., rp n ] ; 1. for all e E c Dened Interactons de P tels que Θ(e) = 0, a est l actvté source et a j l actvté cble de e, s et s j sont nvoqués respectvement a et a j, op et op j sont des opératons de s et s j nvoquées par les actvtés a et a j ; Trouver un chemn fable rp tels que rp = <s m, s m+1,..., s n 1, s n > où can_route(*,s m, m) can_route(s, s m+1, m) can_route(s m, s m+2, m)... can_route(s n 2, s n, m) can_act_from(s n, op j ) for ajouter rp à R P 2. for all e E d Dened Interactons de P tels que Θ(e) = 0, a est l actvté source et a j l actvté cble de e, s et s j sont respectvement par a et a j, op et op j sont des opératons de s et s j sont nvoqués respectvement par les actvtés a et a j ; Trouver un chemn fable rp tels que rp = <s m, s m+1,..., s n 1, s n > où can_out(s m, op, e) can_route(s, s m+1, m) can_route(s m, s m+2, m)... can_route(s n 2, s n, m) can_n(s n, op j, e) for ajouter rp à R P 3. If e E c E d de P avec Θ(e)=0 et l n y a pas de rp ; alors return FALSE ; Algorthm 4: L exemple de recherche de chemns fables 5.6 Producton des procédés coopérants Dans la secton précédente, nous avons détallé la vérfcaton des poltques de flux d nformaton et la producton des chemns fables à travers les servces. Les chemns fables consttuent l entrée du système de producton des procédés coopérants que nous détallons dans cette secton. Selon notre approche, un servce a deux rôles prncpaux. Il établt des nteractons d égal-à-égal avec les autres servces de la composton en exécutant un procédé coopérant. Ans, l peut router ses sortes drectement vers les servces qu dovent les utlser et recevor les données qu l dot utlser drectement de la part des servces qu les fournssent. Le deuxème rôle d un servce est de contrbuer à l ensemble de l exécuton en fasant parte des chemns établs entre les servces qu ne peuvent pas avor d nteracton drecte. Ce deuxème rôle consste à router les données venant d un servce vers un autre servce qu fat auss parte du même chemn. D un pont de vue de la sémantque des procédés coopérants, ces deux rôles sont ndépants. Par conséquent, leur mplémentaton au sen d un unque procédé coopérant que le servce exécute est relatvement dffcle, et de plus cela n est pas nécessare d un pont de vue technque. Nous préférons produre des procédés coopérants séparément pour mplémenter ces deux rôles. Ans, quand un servce est mplqué dans une composton, l exécute un procédé prncpal qu permet d établr des nteractons pour l nvocaton de ses propres opératons. En outre, l exécute, autant de fragments que de chemns sur lesquels l se trouve. Il est à noter que ces derners sont mons sophstqués que le procédé prncpal. Dans cette secton, nous présentons les algorthmes que nous avons utlsés pour produre les 107

124 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace procédés coopérants selon les prncpes c-dessus. Quand un servce s est chos pour être utlsé dans une composton, l exécute un ensemble de fragments de procédé pour cette composton. Cet ensemble de procédé est nommé P s avec P s = {P s, P 1 s, P 2 s,..., P n s } où la varable n est le nombre des chemns fables auquel le servce s contrbue. Le premer procédé de cet ensemble, nommé P s, est le procédé prncpal que s exécute pour contrbuer à l exécuton décentralsée. Les autres fragments ncluent les actvtés de routages des données d un servce et à router vers un autre. Comme présenté dans le chaptre précédent, nous examnons la producton des procédés coopérants en deux partes. La premère consste à étuder la producton des procédés coopérants vs-à-vs des nteractons sortantes. La deuxème étude porte sur la producton des procédés coopérants vs-à-vs des nteractons entrantes. Par rapport aux algorthmes présentés dans le chaptre précèdent, la dfférence essentelle du procédé prncpal P s est la restructuraton des actvtés de connexon et leurs nstancatons vs-à-vs des servces évoqués. L établssement des chemns alternatfs entre les servces nécesste la confguraton des denttés des servces composés. Par exemple, s un servce A évoque un servce B pour mplémenter une restrcton spécfée de la part du servce de A et/ou de B, le procédé coopérant exécuté par le servce A dot référencer le servce B et récproquement le procédé exécuté par le servce B dot référencer le servce A. Dans l mplémentaton des stuatons condtonnelles qu nécesstent le routage des données ou l nvocaton des servces par rapport aux condtons satsfates, les procédés coopérants ne peuvent pas être structurés d une manère séquentelle dans lesquels les actvtés de connexon sont placées sans tenr compte des stuatons condtonnelles mposées par les poltques du flux d nformaton. Dans la sute, nous présentons les algorthmes pour la producton de procédés coopérants qu permettent les nteractons des éléments prncpaux du servce avec les autres procédés coopérants. Les algorthmes 5, 6 et 7 détallent l mplémentaton de l nterconnexon avec les éléments des postsets. Dans ces algorthmes, la structuraton des actvtés de connexon est examnée en tros étapes. Dans un premer temps, les dépances de contrôle correspondantes sont tratées par rapport à leur stuatons dans la classfcaton des nteractons. S la dépance tratée fat parte de l ensemble P ermtted Interactons, dans ce cas, cette dépance est mplémentée comme nous l avons explquée dans le chaptre précédent. On peut dre qu l n y a pas de dfférence d mplémentaton entre une dépance de l ensemble de P ermtted Interactons et une mplémentaton normale du chaptre précédent. S la dépance de contrôle fat parte de l ensemble Dened Interactons, l mplémentaton se fat par l mplémentaton d un chemn fable à travers les servces. Dans ce cas, l actvté de connexon correspondante est ntalsée avec l dentté du premer servce qu est dans le chemn qu remplace la dépance. Ans, le message de contrôle qu caractérse la termnason d une actvté, et, qu sera utlsé comme le message d actvaton de l actvté dépante par rapport au flux de contrôle est routé vers le servce qu est le suvant dans le chemn fable construt. La structuraton des actvtés de connexon qu mplémentent les stuatons condtonnelles est relatvement plus complquée. Les nteractons condtonnelles peuvent être mplémentées de deux manères dfférentes. S la restrcton condtonnelle peut être examnée comme une parte en adéquaton avec les restrctons et une autre parte qu sera tratée comme une dépance dans Dened Interactons. Le deuxème cas est l exstence de pluseurs stuatons condtonnelles dont chacune est remplacée par un autre chemn. Dans ce cas, le procédé coopérant qu exécute l actvté de connexon dot consdérer non seulement une actvté de connexon mas un ensemble d actvtés de connexon pour chacun des servces qu font parte de ces chemns. Les actvtés de connexon qu permettent les nteractons avec les premers servces des chemns fables dovent être structurés d une manère exclusve comme les condtons sont tratées exclusvement en vue de l établssement des chemns correspondants. 108

125 5.6. Producton des procédés coopérants La structuraton des actvtés de connexon qu correspondent aux dépances étues de l ensemble E ext et les dépances de données de l ensemble E d sont tratées de la même manère. Il est à noter que la structuraton exclusve des actvtés de connexon nécesste l évaluaton des données de procédé qu permettent le chox des chemns approprés. Les condtons de transton évaluées ne peuvent pas être évaluée au près d un servce qu n exécute pas les actvtés de connexon. En conséquence, les restrctons du flux d nformaton dovent spécfer des contrantes sur les données qu peuvent être tratées seulement par le procédé coopérant courant de l actvté de connexon envsagée. Dans les cas où les condtons spécfent des restrctons sur des données fournes par d autre servces, les nstances de ces données dovent être transmses au procédé qu va les évaluer pour ntalser les actvtés de connexon. La producton des procédés pour la structuraton des actvtés de connexon est présentée dans les algorthmes 8, 9 et 10 en tros partes. La démarche adoptée est smlare à celle de l nterconnecton des éléments des presets. Des dfférences mneures exstent entre les algorthmes. La dfférence majeure porte sur la récepton des données de procédés et sur les messages de contrôle correspondants. Cela veut dre qu un procédé coopérant peut envoyer un message de suspenson au procédé qu reçot la sorte d une actvté qu sera envoyée par un procédé coopérant. Cette stuaton est formalsée avec des actvtés de connexon exclusves qu sont ajoutées dans le fragment qu sut l actvté orgnale de la spécfcaton centralsée. Comme nous l avons déjà mentonné, la producton des procédés coopérants qu mplémentent le routage des données à travers des chemns fables est relatvement plus smple par rapport à la producton des procédés coopérants prncpaux. L algorthme 11 llustre la formalsaton de cette producton. La producton des chemns fables est explquée dans les sectons précédentes. Dans cette secton, nous présentons seulement la producton des procédés en utlsant les chemns produts. Intutvement, les algorthmes peuvent être explqués comme c-dessous. Le rôle secondare de chaque servce est concrétsé par la récepton d un message d un autre servce et l envo de ce même message au servce qu le sut sur le chemn fable. Ben évdemment, la récepton ou l envo du message routé peut être condtonnée. La récepton est mplémentée par une actvté de connexon de lecture lorsque l envo est mplémenté par une actvté de connexon d écrture. Les stuatons condtonnelles sont mplémentées par les actvtés de connexon structurées d une manère exclusve. La dernère est smlare à l mplémentaton des stuatons condtonnelles au sen du procédé coopérant prncpal. L algorthme 11 trate la producton des fragments de routages en tros partes. S le servce qu fat parte du chemn produt est un élément ntermédare du chemn traté, le procédé de routage Ps est formé de deux actvtés de connexon qu sont ntalsées avec l dentté des servces qu précède et succède ce servce dans le chemn produt. S le servce consttue le premer ou le derner élément du chemn, son dentté est ntégrée dans le procédé coopérant prncpal que le servce exécute. L exemple suvant llustre l utlsaton des algorthmes pour un procédé et un ensemble de poltque du flux d nformaton. Exemple 18 (Producton des fragments coopérants) La fgure 5.3 llustre un exemple de procédé que nous avons déjà utlsé dans dans le chaptre problématque et le chaptre précédent. Il s agt d une spécfcaton centralsée d un procédé à dérver en procédés coopérants. Nous allons étuder deux versons dfférentes du même exemple avec des restrctons dfférentes. Le procédé llustré dans la fgure 5.3 compose pluseurs servces. Les servces que nous utlsons pour cet exemple sont Polce(P), Banque1(B1), Banque2(B2), Hôptal(H), Inspecteur1(I1), Inspecteur2(I2), Lvrason(L). Les actvtés assocées avec ces servces sont : A P ={a 3, a 8 }, A B1 ={a 13, a 14 }, A B2 ={a 15, a 16 }, A H ={a 12 }, A I1 ={a 19 } et A I2 ={a 18 }. Nous ne nous ntéressons pas aux autres actvtés et aux détals de la logque du procédé. Pour faclter la notaton, nous supposons que 109

126 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Input : La spécfcaton centralsée de la composton Les chemns fables, R P Output : a A, ga forall s S do forall a A s do c forall a j a a aj do e E c où source act = a target act = a j, swtch e do case e Permtted Interactons s j = servce(a j ); a T,a j a w (s j, < a j, exec >) case e Dened Interactons rp R P qu remplace e ; Sot s k le premer élément de rp ; a T,a j a w (s k, < a j, exec >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s j = servce(a j ) ; rp R P qu remplace e ; Sot s k le premer élément de rp ; a T,a j a w (s j, < a j, exec >) a w (s k, < a j, exec >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s k le premer élément de rp ; a T,a j a w (s k, < a j, exec >) ; forall a k a F,a j où a F,a j a F do e E c où source act = a target act = a k, swtch e do case e Permtted Interactons s k = servce(a k ) ; a F,a j a w (s k, < a k, skp >) case e Dened Interactons rp R P qu remplace e ; Sot s k le premer élément de rp ; a F,a j a w (s k, < a k, skp >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s j = servce(a j ) ; rp R P qu remplace e ; Sot s k le premer élément de rp ; a F,a j a w (s k, < a k, skp >) a w (s j, < a k, skp >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s k le premer élément de rp ; a F,a j a w (s k, < a k, skp >) ; Algorthm 5: Interconnexon avec les actvtés de postset et de postset étue par rapport aux poltques du flux d nformaton (Premère parte) les opératons des servces ont les mêmes denttés que les actvtés de la spécfcaton centralsée. Par exemple, les opératons du servce B1 sont nommées op 13 et op 14 et les opératons du servce I1 sont nommées op 19. Nous supposons que les poltques du flux d nformaton sont llustrées 110

127 5.6. Producton des procédés coopérants Input : La spécfcaton centralsée de la composton Les chemns fables, R P Output : a A, ga forall s S do forall a A s do forall a k a D,F,a j où a D,F,a j a D,F do e E ext où source act = a target act = a k, swtch e do case e Permtted Interactons s k = servce(a k ) ; a D,F,a j a w (s k, < a, skp, d, a j >) case e Dened Interactons rp R P qu remplace e ; Sot s l le premer élément de rp ; a D,F,a j a w (s l, < a, skp, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s j = servce(a j ) ; rp R P qu remplace e ; Sot s l le premer élément de rp ; a D,F,a j a w (s k, < a, skp, d, a j >) a w (s l, < a, skp, d, a j >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s l le premer élément de rp ; a D,F,a j a w (s l, < a, skp, d, a j >) ; forall a k a D,T,a j où a D,T,a j a D,T do e E ext où source act = a target act = a k, swtch e do case e Permtted Interactons s k = servce(a k ) ; a D,T,a j a w (s k, < a, exec, d, a j >) case e Dened Interactons rp R P qu remplace e ; Sot s l le premer élément de rp ; a D,T,a j a w (s l, < a, exec, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s k = servce(a k ) ; rp R P qu remplace e ; Sot s l le premer élément de rp ; a D,T,a j a w (s l, < a, exec, d, a j >) a w (s k, < a, exec, d, a j >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s l le premer élément de rp ; a D,T,a j a w (s l, < a, exec, d, a j >) ; Algorthm 6: Interconnexon avec les actvtés de postset et de postset étue par rapport aux poltques du flux d nformaton (Deuxème parte) 111

128 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace La spécfcaton centralsée de la composton Les chemns fables, R P a A, ga forall s S do forall a A s do d forall a j a a aj do swtch e E d où source act = a target act = a j do case e Permtted Interactons s j = servce(a j ) ; g a D a w (s j, < a, d, a j >) case e Dened Interactons rp R P qu remplace e ; Sot s k le premer élément de rp ; g a D a w (s k, < a, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s j = servce(a j ) ; rp R P qu remplace e ; Sot s k le premer élément de rp ; g a D a w (s j, < a, d, a j >) a w (s k, < a, d, a j >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s j le premer élément de rp ; g a D a w (s j, < a, d, a j >) ; Algorthm 7: Interconnexon avec les actvtés de postset et de postset étue par rapport aux poltques du flux d nformaton (Trosème parte) dans le tableau 5.7. Il est à noter que ces poltques ne sont pas exclusves. Les poltques consdérées sont les poltques exposées par les servces composés et les poltques contextuelles qu spécfent les relatons d adéquaton entre les servces pour les données routées. Les entrées et les sortes des actvtés sont notées avec les ndces = 1..n. La notaton des varables d entrées et de sortes avec les actvtés auxquelles appartennent. Un tratement ntal de ces poltques donne les nteractons qu dovent être remplacées par des chemns fables entre les servces composés. La dépance de donnée entre l actvté a 12 et l actvté a 19 n est pas en adéquaton avec les poltques exposées par le servce Hôptal et le servce Inspecteur1 par rapport aux poltques du tableau 5.7. S les poltques contextuelles du tableau 5.8 sont tratées, un chemn Hôptal, Banque2, Banque1, Inspecteur1 est trouvé pour la donnée de sorte de l actvté a 12. Ce chemn est nommé rp 1 pour cet exemple. Les servces ntermédares de ce chemn sont Banque1 et Banque2. En conséquence, ls dovent exécuter des fragments pour pouvor router les données de l Hôptal vers le servce Inspecteur1. La fgure 5.4 llustre les fragments de procédés exécutés respectvement par Banque1 et Banque2. Le premer fragment nommé PB2 1 nclut deux actvtés (vor la fgure 5.4). La premère reçot la donnée à router du servce Hôptal (H) et la deuxème actvté envoe la donnée reçue au servce Banque1 (B1). Le procédé coopérant qu mplémente le chemn au sen du servce Banque1 est concrétsé par deux actvtés. La premère reçot la donnée routée de la part du servce Banque2 qu consttue l élément précédent sur ce chemn et la route vers le servce Inspecteur1 (I1). Pour ce fare, l dentté du servce Banque1 est utlsée pour l nstantaton de l actvté de connexon dans le procédé PB2 1 et respectvement l dentté du servce Banque2 est utlsée pour l nstantaton de l actvté de connexon du procédé PB1 1. La fgure 5.6 llustre partellement les procédés prncpaux exécutés par les servces Hôptal et Inspecteur2. Dans ces procédés, nous attrons l attenton sur 112

129 5.6. Producton des procédés coopérants Input : La spécfcaton centralsée de la composton Les chemns fables, R P Output : a A, g a forall s S do forall a A s do c forall a j a a j a do e E c où source act = {a j } target act = {a } ; swtch e do case e Permtted Interactons s j = servce(a j ); a g T a r (s j, < a, exec >) case e Dened Interactons rp R P qu remplace e ; Sot s k le derner élément de rp ; a g T a r (s k, < a, exec >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 s j = servce(a j ) ; rp R P qu remplace e ; Sot s k le derner élément de rp ; g a T a r (s j, < a, exec >) a r (s k, < a, exec >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s k le derner élément de rp ; a g T a r (s k, < a, exec >) ; forall a j a F do e E ext où source act = {a j } target act = {a } ; swtch e do case e Permtted Interactons s j = servce(a j ) ; a g F a r (s j, < a, skp >) case e Dened Interactons rp R P qu remplace e ; Sot s k le derner élément de rp ; a g F a r (s j, < a, skp >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 rp R P qu remplace e ; Sot s k le derner élément de rp ; a g F a r (s k, < a, skp >) a r (s j, < a, skp >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s k le derner élément de rp ; a g F a r (s k, < a, skp >) Algorthm 8: Interconnexon avec les actvtés de préset et de préset étue par rapport aux poltques du flux d nformaton (Premère parte) l ntalsaton des actvtés de connexon qu permettent les nteractons avec les servces qu sont spécfés dans les poltques du flux d nformaton. Il est à noter que les procédés coopérants exécutés respectvement par les servces Banque2 et Banque1 ncluent les dépances de données entre les actvtés de connexon qu caractérsent les données routées. Les actvtés de connexon échangent ces données comme la sorte et l entrée de ces deux actvtés. 113

130 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace Input : La spécfcaton centralsée de la composton Les chemns fables, R P Output : a A, g a forall s S do forall a A s do forall a k a D,F,a j d où a j a a j a do forall a k a F j do e E ext où source act (e) = a k target act (e) = a ; swtch e do case e Permtted Interactons s k = servce(a k ) ; a D,F,a j a r (s k, < a, skp, d, a j >) case e Dened Interactons rp R P qu remplace e ; Sot s k le derner élément de rp ; a D,F,a j a r (s k, < a, skp, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 rp R P qu remplace e ; Sot s l le derner élément de rp ; s k = servce(a k ) ; a D,F,a j a r (s k, < a, skp, d, a j >) a r (s l, < a, skp, d, a j >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e do Sot s l le derner élément de rp ; a D,F,a j a r (s l, < a, skp, d, a j >) forall a k a D,T,a j d où a j a a j a do e E ext où source act (e) = a k target act (e) = a ; swtch e do case e Permtted Interactons s k = servce(a k ); s j = servce(a j ); a D,T,a j a r (s k, < a, exec, d, a j >) + a r (s j, < a, d, a j >) case e Dened Interactons rp R P qu remplace e ; rp j R P qu remplace d s la dépance de donnée est remplacée par un chemn ; Sot s l le derner élément de rp ; Sot s m le derner élément de rp j ; a D,T,a j a r (s l, < a, exec, d, a j >) + a r (s m, < a, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 rp R P qu remplace e ; rp j R P qu remplace d s la dépance de donnée est remplacée par un chemn ; Sot s l le derner élément de rp ; Sot s m le derner élément de rp j ; a D,T,a j (a r (s l, < a, exec, d, a j >) + a r (s m, < a, d, a j >)) (a r (s k, < a, exec, d, a j >) + a r (s j, < a, d, a j >)) case Condtonal Interactons e > 1 forall rp R P qu remplacent e ; rp j R P qu remplace d s la dépance de donnée est remplacée par un chemn ; do Sot s l le derner élément de rp ; Sot s m le derner élément de rp j ; a D,T,a j (a r (s l, < a, exec, d, a j >) + a r (s m, < a, d, a j >)) Algorthm 9: Interconnexon avec les actvtés de préset et de préset étue par rapport aux poltques du flux d nformaton (Deuxème parte) 114

131 5.6. Producton des procédés coopérants Input : La spécfcaton centralsée de la composton Les chemns fables, R P Output : a A, g a forall s S do forall a A s do d forall a j a a j a do swtch e E d do case e Permtted Interactons s j = servce(a j ); g a D a r (s j, < a, d, a j >) case e Dened Interactons rp R P qu remplacent e ; Sot s k le derner élément de rp ; g a D a r (s k, < a, d, a j >) case e Condtonal Interactons swtch e do case Condtonal Interactons + {e} = 1 Condtonal Interactons {e} = 1 rp R P qu remplace e ; Sot s k le derner élément de rp ; g a D a r (s k, < a, d, a j >) a r (s j, < a, d, a j >) case Condtonal Interactons e > 1 forall rp R P qu remplacent e ; Sot s l le derner élément de rp ; do g a D a r (s l, < a, d, a j >) Algorthm 10: Interconnexon avec les actvtés de préset et de préset étue par rapport aux poltques du flux d nformaton (Trosème parte) Input : RP Output: rp j RP, P s forall s de la composton do forall rp j RP do f rp j = <..., s 1, s, s +1,... > then P j s a r (s 1, le message routé) + a w (s +1, le message routé) ; else f rp j = < s, s +1,... > then Intégraton s +1 dans P s else f rp j = <..., s 1, s > then Intégraton s 1 dans P s Algorthm 11: Producton des fragments pour le routage des données à travers 115

132 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace d 6 d 1 a 8 a 9 a 3 a 6 a 17 a 10 a 11 d 0 a 0 a 1 d 4 a 2 d 2 a 5 a 12 a 13 a 15 a 14 a 16 a 18 a 19 a 20 a 7 a 4 d 5 d 3 Fg. 5.3 Exemple de motvaton pour le contrôle du flux d nformaton Polce can_out(out 1, op 9, I1) Banque1 can_act_to(op 14, I2) Banque2 can_act_to(op 14, B1) Hôptal can_out(out 1 (d 5 ), op 12, B2) can_out(out 1 (d 5 ), op 12, P) can_act_to(op 12, B1) can_act_to(op 12, B2) Inspecteur1 can_n(n 1 (d 4 ), op 19, B1) can_n(n 2 (d 5 ), op 19, B1) can_act_from(op 19, I2) Inspecteur2 can_act_to(op 18, I2) can_act_from(op 18, B1) Tab. 5.7 Poltques du flux d nformaton de l exemple can_route(d 5, Banque1) can_route(d 5, Banque2) can_route_to(d 5, Banque2, Banque1) can_route_from(d 5, Banque1, Banque2) can_route_to(d 5, Banque1, Inspecteur1) Tab. 5.8 Les poltques du flux d nformaton contextuelles de l exemple 116

133 5.7. Valdaton de la producton des procédés coopérants a w (H) d 5 P B2 1 a r (B1) a w (B2) d 5 P B1 1 a r (I1) Fg. 5.4 Les fragments coopérants qu permettent le routage de la sorte (P 1 B1 et P 1 B2 ) La deuxème nteracton qu ne peut pas être mplémentée par une nteracton drecte entre les servces sous-jacents est la dépance de contrôle entre l actvté a 16 du servce Banque2 et l actvté a 18 du servce Inspecteur1. Cette dépance peut être remplacée par un chemn passant par le servce Banque1. Nous appelons ce chemn rp 2. Il consttue le deuxème chemn fable de cette composton pour remplacer une dépance. Il est à noter que dans ce cas, le message routé est un message de contrôle qu caractérse la termnason de l actvé a 14. La fgure 5.5 llustre les procédés exécutés par les servces Banque2 et le servce Banque1. Pour le servce Banque2, la fgure llustre le procédé coopérant prncpal PBanque2 qu envoe l nformaton de termnason de l actvté a 16 au procédé PBanque1 2 qu route ensute le même message vers le procédé P 2 Inspecteur Valdaton de la producton des procédés coopérants Dans cette secton, nous nous penchons sur un aspect mportant de la décentralsaton qu est la vérfcaton de l équvalence entre la spécfcaton centralsée et la spécfcaton décentralsée. La composton de servces dans un procédé à partr de laquelle nous dérvons des procédés coopérants, est elle-même une queston de vérfcaton. La composton consste à défnr un modèle exécutable en combnant les nteractons de composants ndépants. Les travaux lés qu portent sur la composton selon l approche centralsée ans que l approche décentralsée cherche à trouver une composton vérfée : les nteractons ne sont pas bloquées par rapport à l hstore d exécuton de la composton ou encore l n y a pas de boucle nfne etc [Pstore et al.2005] [Berard et al.2005]. En effet, la dmenson fonctonnelle de la composton porte essentellement sur la vérfcaton des nteractons des composants. Les crtères vérfés sont typquement ceux du Global Soundness que nous avons présenté dans le chaptre précédent. Notre traval ne concerne pas le problème de la composton d un pont de vue classque. Nous cherchons à créer des procédés qu peuvent coopérer en respectant les crtères de global soundness. Comme nous l avons déjà mentonné, le noton d exacttude de notre approche nécesste une vérfcaton. Une soluton au problème de vérfcaton des procédés coopérants est la vérfcaton a posteror. Ce type de vérfcaton est smlare à répéter le problème de composton en vue d dentfer 117

134 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace a 14 a w (B1) P* Banque2 Le message de contrôle qu content de l nformaton qu correspond à la termnason de l actvté a 14 L actvté de connexon qu reçot le message de contrôle venant du servce Banque2 c a r (B2) a r (I2) P 2 Banque1 L actvté de connexon qu route le message de contrôle c vers le servce Inspecteur2 Fg. 5.5 Les fragments coopérants P Banque2 et P 2 Banque1 118

135 5.7. Valdaton de la producton des procédés coopérants Le message qu content l nformaton de termnason de l actvté a 12 Le message qu content la sorte de l actvté a 12 a w (B1) a 12 a w (B2) a w (B2) P* Hôptal d 5 Le message qu content l nformaton de termnason de l actvté a 12 Le message qu content la sorte de l actvté a 12 a r (B1) d 5 a 19 Les autres messages de contrôles et de données P* Inspecteur2 Fg. 5.6 Les fragments coopérants des servces Hôptal et Inspecteur2, (P Hôptal et P Inspecteur2 ) 119

136 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace cp step cp +1 d cp d cp cp step cp +1 Fg. 5.7 Les structures algèbrques et leur dépances les nteractons qu peuvent causer des stuatons qu volent les crtères d exacttude. C est une approche rasonnable qu peut être utlsée pour la vérfcaton de notre méthodologe qu dérve les procédés coopérants. Pourtant, c est une tâche qu est dffcle. Parce que la même opératon qu produt les procédés coopérants est effectuée pour chaque procédé de composton. La vérfcaton de la cohérence des procédés coopérants dot être consdérée pour l opératon qu les dérve. Ans, la vérfcaton, même s elle est dffcle, est effectuée une seule fos. Pour ce fare, nous fasons une vérfcaton formelle des algorthmes développés en vue de la détermnaton de la relaton d équvalence entre la spécfcaton centralsée et les procédés coopérants dérvés. Pour cela, nous nous penchons sur les défntons formelles et les algorthmes présentés dans le chaptre précédent. Dans la lttérature, l y a pluseurs travaux qu portent sur la vérfcaton de l équvalence engrée par un système de transformaton [Wodtke and Wekum1997] [Harel and Naamad1996] [Emerson1990] [Leung and Reghbat1987]. Notre technque est nsprée de ceux-c. Mas, elle est adaptée au formalsme que nous avons proposé. Premèrement, nous défnssons une varable qu décrt le contexte d exécuton d un procédé. L ensemble des contextes d exécuton d un procédé est nommé CP. Chaque contexte du procédé cp CP décrt les valeurs des varables du procédé, l état d exécuton des actvtés, les condtons de transtons évaluées. Pour le contexte du procédé, nous défnssons une opératon step qu transforme un contexte cp du procédé en son contexte suvant cp +1. Il est à noter qu l peut y avor pluseurs contextes suvants. Le noton de contexte exste auss pour les procédés coopérants. Pourtant, dans ce deuxème cas, le contexte est dspersé entre les procédés coopérants au leu d appartenr à un seul procédé. L ensemble des contextes des procédés coopérants est nommé CP. Chaque élément de CP est nommé cp. Nous utlsons une opératon step qu transforme un contexte cp de CP dans les contextes suvants cp +1. Les deux structures qu consttuent respectvement l entrée et la sorte de mécansme proposé sont consdérées comme des structures algébrques où le contexte est l ensemble et l opératon step est une lo de composton assocée. Entre les deux algèbres qu correspondent respectvement à la spécfcaton centralsée et à ses procédés coopérants qu smulent son comportement, l est possble de trouver une dépance d cp. La relaton d cp est une foncton qu assoce chaque contexte de la spécfcaton centralsée à un contexte des procédés coopérants. Plus formellement, d cp : CP CP. L assocaton de foncton d cp des contextes consste à coupler les éléments respectfs des contextes. La fgure 5.7 llustre les relatons entre les contextes, l opératon de transformaton et la foncton qu assoce les contextes. La premère lgne de cette fgure consttue l algèbre qu correspond à la spécfcaton centralsée alors que la deuxème lgne correspond à l algèbre des procédés coopérants. S les dépances de la fgure 5.7 sont commutatves alors la deuxème algèbre est l homomorphsme de la premère algèbre [Wodtke and Wekum1997] [Muth et al.1998]. Par 120

137 5.8. Synthèse conséquent, nous pouvons dre que le comportement des procédés coopérants et le comportement de la spécfcaton centralsée sont équvalents. Cela veut dre que quand la spécfcaton centralsée dans un contexte, le même contexte est mse en œuvre par les procédés coopérants. On y trouve les mêmes varables, les mêmes condtons de transton, et les mêmes états d exécuton d actvtés etc. Plus formellement, ce théorème est décrt c-dessous. Théorème 2 (L homomorphsme entre la spécfcaton centralsée et les procédés coopérants) La foncton d cp qu assoce chaque contexte cp de la spécfcaton centralsée à un contexte cp des procédés coopérants est un homomorphsme s la relaton de commutatvté suvante est vrae : d cp (step(cp )) = step (d cp (cp )) La preuve de ce théorème est dans l annexe C. 5.8 Synthèse Dans cette secton, nous résumons les contrbutons de ce chaptre et nous présentons notre postonnement par rapport aux travaux lés. Dans ce chaptre, nous avons présenté une approche de contrôle de flux d nformaton dans une composton de servce. Le problème du contrôle du flux d nformaton est rédut à celu de la producton de procédés coopérants qu permettent des nteractons conformes aux poltques du flux d nformaton. Pour ce fare, l approche présentée dans le chaptre précédent est adaptée aux exgences de la producton des procédés coopérants qu dovent mplémenter le flux d nformaton. En vue de la modélsaton des poltques de flux d nformaton, nous avons proposé une spécfcaton compréhensble qu regroupe les poltques qu peuvent exster dans un contexte de composton. Il faut tout de même dre que les poltques consdérés ne reflètent pas la réalté du contexte à partr de laquelle ls explctent les nteractons qu dovent être mplémentées. En partculer, l n est pas toujours auss évdent de donner un énoncé ntal d un problème de défnton de ce type de restrctons. À la mesure du fosonnement actuel de domane, l n est pas possble de modélser tous les poltques qu exstent dans un contexte de composton. Tout en étant complémentares, chacun de ces types de poltque peut devenr prmordal en foncton de la classe du problème traté. L exemple par excellence est la modélsaton de la séparaton des devors dans les systèmes de geston de workflow. Ces restrctons peuvent consster à défnr des smples restrctons qu spécfent l assocaton des acteurs aux actvtés tels que [Bertno et al.1999] [Atlur and Warner2005] et des restrctons qu consstent à spécfer le contexte temporel ou spatal de la séparaton des devors [Josh et al.2005] [Daman et al.2007]. Même s les poltques que nous avons défnes restent smples par rapport aux travaux relatfs, elles sont caractérstques des nteractons atomques. D autres types de poltques peuvent être exprmées en utlsant les poltques présentées dans ce chaptre. Enfn, le derner mas non le mondre des aspects caractérstques des modèles que nous avons abordés dans ce chaptre, concerne le fat qu un modèle peut ou non supporter les poltques dynamques. Les restrctons peuvent exprmer des cas de fgures qu ne sont pas tratables avant l exécuton du procédé. La 121

138 Chaptre 5. Contrôle du flux d nformaton :Vers un modèle décentralsé effcace geston de restrctons peut être fate sot de façon statque à l ade du tratement des poltques, sot de façon dynamque à l ade d une unté centralsée qu trace l exécuton des procédés. Nous avons seulement consdéré les poltques qu on peut trater de façon statque et les poltques hybrdes qu consdèrent les attrbuts condtonnels. Ces derners peuvent être planfés de façon statque. Du fat de l enjeu économque que cela mplque, le contrôle du flux d nformaton consttue un problème fondamental dans le cycle de ve d un procédé méter qu spécfe la composton d un ensemble de servces. Ces problèmes se posent en général dès les premères nvestgatons, mas peuvent auss se poser dans des étapes très avancées du processus de concepton du procédé, vore encore plus tard en phase d exécuton. Le tratement effcace des poltques permet de détermner les melleurs comproms pour trouver des exécutons fasables à partr de poltques qu peuvent être mutuellement contradctores. Le contrôle du flux d nformaton est un sujet d étude relatvement nouveau dans le contexte des procédés méters et la composton des servces. Même s des exemples relatfs exstent dans les pstes de recherche proches tels que la séparaton des devors [Bertno et al.1999], les drots d accès [Mecella et al.2006], les travaux qu portent sur le contrôle du flux d nformaton ne sont pas nombreux. Deux exemples prncpaux qu mértent d être mentonnés sont [Atlur et al.2001] et [Chafle et al.2005]. Le premer consste à mplémenter des modules logcels pour router l nstance du procédé d un servce à l autre selon l approche mult-agents. Le derner qu est plus proche de l approche présentée dans ce chaptre consste à calculer tous les fragments coopérants d un procédé et élmner ceux qu ne respectent pas les restrctons exgées. De par son caractère nnovant, le contrôle du flux d nformaton selon cette approche permet une concepton progressve d une exécuton décentralsée face aux restrctons prncpales qu gouvernent les nteractons et faclte le passage d une spécfcaton à une exécuton [Yldz and Godart2007d] [Yldz and Godart2007c] [Yldz2008]. L ade que nous apportons au concepteur et aux organsatons qu mplémentent les servces n est pas seulement de la séparaton de la logque du procédé et les restrctons secondares, mas auss le fat de fournr une plate-forme dans laquelle ces restrctons sont tratées en vue de fournr une exécuton fable. 122

139 Chaptre 6 L mplémentaton du chox dynamque et décentralsé des servces Sommare 6.1 Introducton Chox dynamque et décentralsé de servces Exemple de motvaton et vue d ensemble Aspects formels du chox dynamque et décentralsé Chox concurrent de servces Chox dynamque par défaut Déploement des procédés coopérants à travers les dépances de chox Extenson de l approche par des consdératons d mplémentaton Chox dynamque et décentralsé retardé Synchronsaton explcte de servces Implémentaton du chox dynamque et décentralsé dans WS-BPEL Synthèse Introducton Notre vson de l exécuton décentralsée consste à déployer des procédés coopérants vers les servces composés afn d établr des nteractons d égal-à-égal entre eux. La producton des procédés coopérants est effectuée à partr d une spécfcaton centralsée de la composton. Il est à noter que le déploement des procédés coopérants est fat par le servce qu aurat été le coordnateur centralsé dans une exécuton centralsée. Une des crtques que l on peut fare à cette approche est la centralsaton de l opératon de déploement des procédés coopérants. Comme nous l avons déjà soulgné, un des crtères d effcacté permettant d attendre les objectfs d une exécuton décentralsée est également la décentralsaton des fonctons telle que le déploement des procédés coopérants. Permettre la décentralsaton de l opératon de déploement des procédés coopérants demande de répondre à pluseurs questons. Comment les servces se chosssent-ls les uns les autres? Comment les procédés coopérants sont déployés d une manère décentralsée? Quels sont les problèmes de synchronsaton qu peuvent être rencontrés? 123

140 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces Les contrbutons présentées dans les chaptres précédents portaent sur la producton des procédés coopérants. Plus précsément, nous avons étudé les aspects lés à la structuraton des actvtés de la spécfcaton centralsée en procédés coopérant par l mplémentaton des actvtés de connexon. Dans un premer temps, nous avons consdéré la décentralsaton d un procédé centralsé sans tenr compte de restrctons partculères. Dans un deuxème temps, nous avons consdéré les restrctons partculères telles que les poltques de flux d nformaton. La contrbuton de ce chaptre porte sur l étude d un autre aspect : nous ne nous ntéressons pas à la producton des procédés coopérants, mas nous étudons les problèmes lés à leur déploement de façon dynamque. Le reste de ce chaptre est organsé de la manère suvante : la prochane secton détalle le noton du chox de dynamque et décentralsé et l llustre à travers un exemple de motvaton. Ensute, nous dscutons les problèmes lés à l mplémentaton du chox dynamque et décentralsé des servces tels que ceux lés à la synchronsaton du chox concurrent. Nous développons une soluton générque pour le chox dynamque et décentralsé de servces. La contrbuton présentée dans ce chaptre n est pas ndépante des contrbutons présentées dans les chaptres antéreurs. Elle consdère une autre dmenson de la décentralsaton effectuée par des procédés coopérants. 6.2 Chox dynamque et décentralsé de servces Le chox dynamque des servces est un avantage nhérent aux archtectures orentées servces où les concepteurs de procédés ont la possblté de chosr un servce lors de l exécuton de procédé. Au moment de la modélsaton d un procédé composé, on peut dentfer les servces à utlser sans dentfer l nstance précse du servce. Dans ce cas, une nstance de servce qu va satsfare la fonctonnalté dot être chose au moment de l nvocaton. Ben sûr, le chox dynamque nécesste des mécansmes qu mantennent et mettent à jour un répertore de servces. Ans un servce nécessare peut être dynamquement chos à partr du répertore qu content la lste des servces dsponbles. L mplémentaton du chox dynamque de servces n est pas dffcle dans un système de geston de procédé centralsé. Mas la complexté augmente consdérablement dans un contexte décentralsé. Dans un contexte décentralsé où un servce chost dynamquement un autre servce et déploe le procédé coopérant correspondant, l est nécessare de formalser deux opératons pour empêcher les stuatons de blocage et de synchronsaton que nous détallons c-dessous [Nanda and Karnk2004] [Yldz and Godart2007e] [Yldz and Godart2007b]. La complexté de la formalsaton de chox dynamque est lée naturellement à la complexté de la spécfcaton du procédé décentralsé lu même. Lors d une exécuton centralsée, le système de geston de procédés est mun d un module de chox dynamque de servce qu effectue cette tâche en se basant sur pluseurs crtères. L approche est smlare à l mplémentaton de la séparaton des devors dans les systèmes de geston de workflow [Bertno et al.1999] [Josh et al.2005] [Daman et al.2007]. Elle consste à défnr et à satsfare des poltques qu spécfent les relatons entre les utlsateurs et les actvtés d un procédé. Ces relatons peuvent être défnes selon une approche dynamque. En outre, la dynamcté peut dépre d aspects temporels, condtonnels ou encore spataux. Dans un contexte décentralsé, nous consdérons ce problème comme un problème de chox d égal-à-égal des servces. Ce pont de vue est appropré au contexte consdéré mas n est pas traté dans les propostons exstantes basées sur la séparaton des devors. Il est à noter que nous ne dscutons pas toutes les restrctons relées à l mplémentaton du chox dynamque et décentralsé des servces. Nous lmtons notre contrbuton aux cas prncpaux qu peuvent être reformulés pour les cas partculers. Plus précsément, ces aspects, lés à l mplémentaton des canaux de communcatons, sont dscutés 124

141 6.2. Chox dynamque et décentralsé de servces dans la secton synthèse Exemple de motvaton et vue d ensemble Dans cette secton, nous reprenons l exemple de motvaton du chaptre 2. Dans cet exemple, le servce Assurance peut chosr les servces composés statquement avant de commencer l exécuton ou les chosr dynamquement pant l exécuton du procédé. Dans une exécuton décentralsée mplémentée avec des procédés coopérants, le même servce chost les servces et déploe leur procédé respectf. S le chox dynamque est exgé, le servce Assurance dot effectuer les mêmes opératons d une manère dynamque. Afn d évter le rôle centralsé du servce Assurance, nous souhatons mplémenter le chox des autres servces de façon dynamque et décentralsée. Par exemple, le servce Polce et/ou le servce Hôptal peuvent être capable de chosr drectement un servce Inspecteur pour trater les données qu ls lu fournssent. De même, Inspecteur peut être capable de chosr un servce Banque. Afn de permettre l nteracton du servce chos avec les autres servces dépants, l opératon de chox dynamque dot être suve par le déploement du procédé coopérant correspondant. La fgure 6.1 llustre respectvement les dépances de chox dynamque des servces dans une exécuton centralsée (a) et décentralsée (b). Les flèches vertes llustrent le servce qu chost et le servce chos. Comme nous l avons déjà soulgné, l mplémentaton décentralsée du chox dynamque nécesste un système de geston pour trater les dépances de chox entre les servces composés. Pour ce fare, nous analysons la spécfcaton centralsée de composton afn d en extrare les dépances qu formalsent le chox dynamque. Il est à noter que le problème essentel que nous cherchons à résoudre est l dentfcaton des couples de servces, consttués d un servce qu chost l autre. Nous abordons ce problème de façon générale sans nous baser sur un crtère partculer, comme un aspect temporel ou un aspect condtonnel. Cette approche par défaut sut un prncpe smple qu consste à chosr un servce au moment de son nvocaton. Ans, un procédé de composton peut être défn avec des servces générques ne fasant pas référence à des nstances précses de servces. Lors de l exécuton, les servces générques sont remplacés par des nstances nvocables et les procédés coopérants sont déployés afn de permettre l nteracton du servce chos avec les autres servces. Le chox d un servce au moment où l est utlsé est une approche par défaut. Un autre pont de l approche porte sur l dentfcaton du servce qu va chosr ce servce. Intutvement, on peut consdérer que c est le premer servce qu s exécute avant le servce chos qu est le servce sélecteur. Il est mportant de soulgner encore une fos que nous défnssons les relatons entre les servces sans nous baser sur un crtère précs qu gouverne l opératon de sélecton. La fgure 6.2 llustre les dépances de sélecton entre les servces. Ces relatons défnssent un ordre partel d nvocaton des servces sans prre leur aspects conversatonnels en compte. Cela veut dre que nous supposons que deux actvtés dfférentes n nvoquent pas le même servce. Dans cette fgure, nous soulgnons deux aspects mportants. Le premer est le cas des actvtés conversatonnelles. Les actvtés conversatonnelles peuvent nécesster l nvocaton du même servce pour l exécuton d actvtés dfférentes. Dans ce cas, s un servce est chos dynamquement dans une conversaton, l faut que la même nstance du servce chost sot utlsé pour toutes ses actvtés conversatonnelles. C est le cas du servce Lvrason qu est le cble de deux dépances. Le deuxème pont mportant est le chox concurrent des servces. S l ordre d nvocaton des servces est utlsé pour formalser le chox dynamque, un servce précédé par pluseurs servces (par exemple le servce Inspecteur) dot être chos par l ensemble des servces qu exécutent ces actvtés dépantes. C est le cas du servce Inspecteur qu est le cble de pluseurs dépances de chox dynamque entrantes. 125

142 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces Lvrason Inspecteur Polce a 1 :H d1 d3 d4 a 5 :L a 2 :L a 4 :Ins Assurance a 3 :P a 6 :B d2 Banque Hôptal Lvrason Inspecteur Polce a 1 :H d1 d3 d4 a 5 :L a 2 :L a 4 :Ins Assurance a 3 :P a 6 :B d2 Banque Hôptal Fg. 6.1 Le chox dynamque centralsé (a) et décentralsé (b) 126

143 6.3. Aspects formels du chox dynamque et décentralsé Lvrason Polce Assurance Banque Hôptal Inspecteur Fg. 6.2 Les dépances de chox dynamque et décentralsé Nous avons assocé l opératon du chox d un servce à celu qu le précède dans le flux de contrôle de la spécfcaton centralsée. Dans une exécuton décentralsée effectuée par des procédés coopérants, cet ordre de sélecton dot être préservé. On peut faclement remarquer que la défnton des dépances de sélecton entre les servces peut causer des problèmes de chox concurrent des servces. Cette stuaton de concurrence est lée à la complexté de la spécfcaton centralsée du procédé de composton. Dans le reste du chaptre, nous étudons le chox dynamque et décentralsé des servces en nous penchant sur les problèmes lés au chox concurrent de servces. Notre approche formalse les concepts lés au chox dynamque et décentralsé de servces et les solutons qu empêchent les stuatons de blocages. Nous termnons notre dscusson par une analyse crtque. 6.3 Aspects formels du chox dynamque et décentralsé Dans cette secton, nous formalsons le concept de chox dynamque et décentralsé des servces d une composton. Comme nous l avons soulgné, le chox dynamque et décentralsé défnt une relaton de dépance entre deux servces. Nous la formalsons c-dessous. Défnton 1 (Dépance de chox) Une dépance de chox, d chs, est un tuple (s, s j ) S S où s est le servce qu chost l nstance du servce s j. La défnton c-dessus consdère les relatons de chox entre les servces. Pourtant, les servces peuvent être nvoqués par des actvtés. Cec nécesste la consdératon des aspects conversatonnels des actvtés pour l dentfcaton des dépances de chox. Pour ce fare, nous déléguons les dépances de chox de servces aux actvtés du procédé auquel elles appartennent. Cdessous, nous donnons la défnton formelle de chox dynamque projeté sur les actvtés. 127

144 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces Défnton 2 (Dépance de chox des actvtés) Une dépance de chox d actvtés, d cha, est un tuple (a, a j ) A A où servce(a ) = s et servce(a j ) = s j et s chost l nstance du servce s j. Les dépances du procédé ne sont pas lmtées à des dépances de contrôle. Les dépances de données sont également concernées par le chox dynamque et décentralsé de servces. En effet, une actvté qu fournt une donnée à une autre actvté peut être exécutée par un servce qu sera le premer dans l ordre d nteracton avec le servce nvoqué par l actvté cble de la dépance. Auss un servce peut fare l objet du chox dynamque par n mporte quel servce nvoqué par les actvtés sources de ses dépances entrantes. La multplcté des dépances entrantes est la rason essentelle du problème du chox concurrent de servce Chox concurrent de servces Dans un contexte dans lequel les servces chosssent dynamquement d autres servces, le chox concurrent d un servce par pluseurs servces rsque de condure à des nstances dfférentes par les dfférent servces. Dans une exécuton décentralsée correcte, un servce est chos par un seul servce et son dentté propagée vers les autres servces dépants. La fgure 6.2 llustre un exemple de chox concurrents où les servces se chosssent les uns les autres suvant l ordre d nvocaton et un servce qu est précédé par pluseurs servces est chos pluseurs fos. S les nstances choses sont les mêmes, l n y a pas de problème de synchronsaton entre les servces dépants qu ont des nteractons avec le servce chost. Pourtant, cec n est pas une hypothèse rasonnable dans le contexte de Web dans lequel on peut faclement trouver pluseurs servces qu ont la même compétence. En conséquence, le chox de servce dot être traté afn d empêcher des stuatons de concurrence. La défnton 3 formalse les servces qu font l objet du chox concurrent. Défnton 3 (Chox du servce concurrent) Un servce s fat l objet du chox concurrent s a, a j A s où d cha = (a k, a ) et d cha = (a l, a j ) avec servce(a k ) servce(a l ). De plus, a et a j ne sont pas précédées par une autre actvté conversatonnelle. Plus formellement, a z A s tels que a z < a a z < a l. Informellement nous pouvons défnr une stuaton de chox concurrent comme sut. La premère actvté conversatonnelle qu nvoque un servce peut être précédée par pluseurs servces. Les servces qu sont susceptbles de chosr le servce peuvent être dépants de ce servce par les dépances de contrôle ou de donnée. Les servces sélecteurs eux-mêmes peuvent être dépants par le flux de contrôle ou de donnée. Afn d empêcher les stuatons de concurrence dans lesquelles un servce peut être chos par pluseurs autres servces, un unque servce sélecteur dot être dentfé pour effectuer le chox du servce. La défnton de ce servce n est pas une opératon ntutve car celle-c est lée à la complexté du procédé qu spécfe la composton. Dans le reste de cette secton, nous développons deux solutons au chox concurrent des servces. La premère consste à mplémenter le chox dynamque et décentralsé d une manère fable où un servce chost un autre servce et l dentté du servce chos est propagée vers les autres servces dépants pour permettre leurs nteractons. La deuxème proposton porte sur la proposton 128

145 6.3. Aspects formels du chox dynamque et décentralsé d un mécansme de chox dynamque qu assure la synchronsaton avec le support du chox retardé de servce. Avec cette approche, nous mplémentons un système de synchronsaton entre les servces qu dovent chosr un servce commun. Ans, un servce peut être dynamquement chos avant son nvocaton Chox dynamque par défaut Comme nous l avons soulgné c-dessus, le chox dynamque par défaut consste en l dentfcaton d un servce de telle sorte que les autres servces dépants soent nformés du chox effectué pour empêcher les problèmes lés à la synchronsaton. Notre pont de départ pour l dentfcaton des servces est naturellement la spécfcaton centralsée du procédé. D après la défnton 3, les servces nvoqués par les actvtés qu ont pluseurs dépances entrantes font l objet du chox concurrent. Afn d explquer le chox concurrent, nous utlsons les sous-concepts suvants qu projettent les dépances du procédé vers les dépances du chox de servce. Une dépance de contrôle ou de donnée entre deux actvtés mplque l exstence d une dépance de chox de servce entre le servce nvoqué par l actvté cble et le servce nvoqué par l actvté source. Nous appelons cette dépance une dépance mnmale de chox nommé mnbnd(s, s j ). Afn d dentfer un servce sélecteur s qu fera le chox d un servce s j, nous tratons d abord les actvtés conversatonnelles. La premère actvté conversatonnelle est tratée afn d dentfer s elle fat l objet de chox concurrent ou pas. S c est le cas, nous tratons les actvtés qu cble celle-c en consdérant les servces qu sont nvoqués. Il est à noter qu une unque actvté conversatonnelle qu précède toutes les autres actvtés dépantes n exste pas forcement. S ce n est pas le cas, un autre servce, qu n est pas forcement par une actvté conversatonnelle, peut être utlsé. Nous explquons les cas prncpaux dans les exemples de motvatons suvants. Exemple 19 (Cas 1) La fgure 6.3 llustre tros actvtés qu nvoquent tros servces dfférents. Selon l approche de l exécuton décentralsée, ces tros servces exécutent tros procédés nommés P s9, P s11, P s17. Il est à noter que les actvtés orgnales de la spécfcaton centralsée sont structurées dans ces procédés. Nous souhatons mplémenter le chox dynamque et décentralsé pour le servce s 17. Cela veut dre que le servce s 17 dot être chos au moment où l dot être utlsé. L nvocaton du servce s 17 est fate après la termnason des actvtés précédentes. Dans ce cas, les servces qu exécutent les actvtés précédentes dovent chosr un servce s 17 et déployer P s17. Pourtant s s 9 et s 11 chosssent un servce en même temps, elles peuvent chosr un servce dfférent. Dans ce cas, un seul servce dot effectuer le chox du servce s 17, de plus ce même servce dot dffuser l dentté du servce chos vers les servces dépants. Exemple 20 (Cas 2) Le fgure 6.4 llustre tros actvtés qu nvoquent tros servces dfférents. Le servce s 3 qu exécute a 6 ne peut pas être chos avant les deux servces qu exécutent respectvement a 1 et a 3. Même s ces servces ne sont pas concurrents, la sélecton de s 6 par les deux posent un problème de synchronsaton. Par rapport au cas précédent, ce cas llustre le fat que les dépances entrantes des actvtés séquentelles entre les actvtés peuvent causer une stuaton problématque. Cela est essentellement lé à la présence des dépances de donnée des actvtés précédentes. Exemple 21 (Cas 3) La fgure 6.5 llustre cnq actvtés qu nvoquent quatre servces dfférents. Nous supposons que les actvtés a 9 et a 11 nvoquent le même servce s 3. Les actvtés conversatonnelles qu nvoquent le servce s 3 sont concurrentes. Même s chacune de ces actvtés est précédée par une seule actvté (a 8 et a 10 ), le servce s 3 ne peut pas être chos par les 129

146 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 d4 a2 a13 a14 d2 a12 a18 a19 a20 a5 a15 a16 a7 a4 d5 d3 Fg. 6.3 Cas 1 : La sélecton du servce s 17 qu exécute a 17 d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 d4 a2 a13 a14 d2 a12 a18 a19 a20 a5 a15 a16 a7 a4 d5 d3 Fg. 6.4 Cas 2 : La sélecton du servce s 3 qu exécute a 6 d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 d4 a2 a13 a14 d2 a12 a18 a19 a20 a5 a15 a16 a7 a4 d5 d3 Fg. 6.5 Cas 3 : La sélecton du servce s 3 nvoqué par les actvtés a 9 et a

147 6.3. Aspects formels du chox dynamque et décentralsé servces qu exécutent ces deux actvtés en même temps car cela peut faclement causer un chox multple. Les tros exemples c-dessus llustrent le chox dynamque et décentralsé par rapport à la spécfcaton du procédé. Dans tous ces cas, la dépance mnbnd dot être révsée avec les dépances de chox approprées afn d empêcher les chox concurrents. Cette dépance est caractérsée dans la spécfcaton du procédé. Nous l appelons bnd. C-dessous nous dscutons l dentfcaton de celle-c. La défnton 4 donne la représentaton formelle de la dépance de type bnd. Défnton 4 (La dépance bnd) Une dépance de type bnd est un uplet (a, a j ) A A où s = servce(a ) et s j = servce(a j ). Le servce s est l unque servce qu chost le servce s j. Comme la défnton 4 le décrt, la dépance bnd exprme une relaton entre deux actvtés. Le servce nvoqué par l actvté source de la dépance est responsable du chox du servce nvoqué par l actvté cble. La queston prncpale est l dentfcaton des dépances de chox à partr de la spécfcaton centralsée. Il est à noter que le but ultme de ce tratement est l dentfcaton d un servce unque pour le chox d un servce et la propagaton de son dentté vers les autres servces dépants. L algorthme 12 défnt l opératon qu dentfe les servces sources des dépances bnd. Nous pouvons défnr le chox du servce source comme sut. Dans le cas des actvtés conversatonnelles, le tratement est effectué pour la premère actvté des actvtés conversatonnelles dans le flux de contrôle. S une actvté conversatonnelle unque qu précède les autres n exste pas ou elle exste mas fat l objet d un mnbnd, un servce unque dot être sélectonné. Ce servce est naturellement nvoqué par l actvté qu précède l actvté(s) pour laquelle le servce nvoqué fat l objet du chox concurrent. Le chox dot être effectué suffsamment tôt pour que l dentté du servce pusse être propagé vers les servces dépants. Pour ce fare, nous avons développé un algorthme qu dentfe le premer servce qu précède les actvtés conversatonnelles dans l ordre partel du procédé. La sélecton des servce et le déploement des procédés coopérants sont effectués par ce servce de telle sorte que les problèmes de synchronsaton soent évtés. L algorthme 12 défnt le mécansme qu dentfe les couples de servces sélecteur et chos comme défn dans la défnton 4. Il est à noter que nous avons magné les cas extrêmes dans lesquels chaque servce composé est dynamquement chos. Exemple 22 (Identfcaton de servce sélecteur) La fgure 6.6 llustre le procédé de l exemple de motvaton. Nous examnons le chox du servce nvoqué par l exécuton de l actvté a 19. Nous assumons que l actvté a 19 est la premère actvté qu nvoque le servce concerné. Dans ce cas, le plus complqué, chaque actvté est exécutée par un servce dfférent. Nous dentfons les servces avec les numéros que les actvtés qu les nvoquent s 1,..., s 20. Les relatons de dépance de chox exstent entre les actvtés (a 4, a 19 ), (a 9, a 19 ), (a 12, a 19 ), (a 13, a 19 ) et (a 18, a 19 ). La structuraton des actvtés sources des dépances de chox correspond aux cas 3 que nous avons présenté c-dessus. Dans ce cas, les actvtés cbles sont concurrentes. En conséquence, une actvté qu précède ces actvtés dot être la source de la dépance de chox. Par rapport à cette spécfcaton, c est l actvté a 1. C est la premère actvté qu précède toutes les actvtés 131

148 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces Input : La spécfcaton du procédé Output: Les relatons bnd forall s S do forall a A s do f A s >1 then f a, a j A s, a a j a j a j then sot a z la premère actvté qu précède a z <a a z <a j bnd(a z, a ) bnd(a z, a j ) else sot a z, mnbnd(a z, a ) mnbnd(a z, a j ) else Algorthm 12: L dentfcaton du servce qu effectue la sélecton qu fat l objet de problème de synchronsaton sources des dépances de chox. La fgure 6.6 llustre la propagaton de l dentté du servce chos vers les servces concernés à partr du servce qu fat la sélecton. Ben évdemment, les dépances lant les actvtés du procédé exprment les relatons des servces sous-jacents Déploement des procédés coopérants à travers les dépances de chox Dans notre modèle d exécuton décentralsé, chaque servce exécute un procédé coopérant. La composton d un servce au sen d un procédé est suve par le déploement de ce procédé coopérant dans le procédé englobant. Dans les chaptres précédents, cette opératon état effectuée par un servce centralsé. Les procédés coopérants mplémentaent les nteractons d égal-à-égal. Selon l approche que nous présentons dans ce chaptre, cette opératon est mantenant décen- d6 d1 a8 a9 a3 a6 a17 a10 s 19 s 19 a11 d0 a0 a1 d4 a2 s 19 d2 s 19 a12 a13 a14 a18 a19 a20 s 19 a5 a15 a16 a7 a4 d5 d3 Fg. 6.6 La chox du servce s 19 nvoqué par l actvté a

149 6.3. Aspects formels du chox dynamque et décentralsé tralsée. En conséquence, tous les procédés coopérants ne sont pas déployés par un seul servce. Pusque le déploement des procédés est codé au sen des procédés coopérants, un servce dot être capable d nvoquer un autre servce en déployant son procédé coopérant. Cette opératon elle-même dot être nclue au procédé exécuté par le servce sélecteur. On peut mplémenter ce mécansme en ncluant un procédé coopérant dans un autre comme une varable de procédé. Ans,au moment du chox d un servce, son procédé coopérant peut être déployé par celu qu le chost en exécutant l opératon de déploement. Pour un servce sélecteur, son procédé coopérant est en effet une sére de procédés mbrqués qu consttuent les procédés à déployer. La producton des procédés coopérants n est pas changée au nveau de la structuraton des actvtés de connexon. Une opératon qu trace les dépances de déploement est exécutée pour mbrquer les procédés coopérants. L exemple 23 décrt une exécuton de l algorthme pour l exemple de motvaton ntrodut. Exemple 23 (L dentfcaton du servce sélecteur et déploement des procédés coopérants) La fgure 6.7 llustre un exemple de procédé. Dans ce procédé, nous nous ntéressons au chox du servce qu exécute l actvté a 12. Nous supposons que l nstance du servce nvoqué par cette actvté n est pas connue pant la concepton du procédé de composton. Nous appelons ce servce s x. Selon le prncpe de chox dynamque et décentralsé, ce servce va être chos par les autres servces pant l exécuton. Il est à noter que les procédés coopérants sont dérvés statquement avant le début de l exécuton. La premère approche de chox dynamque mpose que le servce s x sot chos avant son nvocaton de telle sorte que les problèmes de synchronsaton soent évtés. Par rapport à l approche ntutve que nous avons résumée c-dessus, le servce s x a des dépances de chox avec d autres servces. Ces servces sont assocés avec les actvtés dépantes de a 12 par rapport aux dépances entrantes. Nous les appelons respectvement s 2, s 7 et s 17. Il est à noter que ces servces peuvent être dynamquement choss à leur tours. Les dépances de chox sont notées mnbnd(s 2, s x ), mnbnd(s 7, s x ) et mnbnd(s 17, s x ). Il est à noter que l actvté a 12 est la premère actvté qu sera exécutée par le servce s x. En conséquence, une nstance de servce dot être chose pour celu-c. Les servces s 2 et s 7 sont séquentels. Donc s le chox est effectué par le servce s 2, le servce s 7 peut être nformé de l dentté du servce chos pour s x. Mas l exécuton de l actvté a 17 par le servce s 17 est concurrente à ces deux servces. L algorthme 12 cherche un servce commun à ces tros servces concurrents pour dentfer la source de la dépance de chox dynamque. Le premer pont de dsjoncton qu précède le servce s 17 est l actvté a 6. Mas, le servce qu exécute cette actvté ne précède pas les servces qu exécutent les actvtés a 7 et a 2. Le servce, nous l appelons s 1, qu exécute l actvté a 1 précède les tros actvtés concurrentes. Cette actvté est la dernère actvté qu précède les actvtés par rapport au flux de contrôle (l ordre partel des actvtés). Le déploement des procédés coopérants est effectué selon l ordre d mplémentaton du chox dynamque. Les procédés de cette composton sont nommé respectvement P s1, P s2, P s3,..., P s17. Des dépances de chox exstent entre les actvtés a 1 et a 2, et, a 1 et a 3. Cec veut dre que le servce s 1 est responsable pour le chox de s 2 et s 3. Le déploement des procédés coopérants P s2 et P s3 sont effectués par le servce s 1 qu exécute P s1. En conséquence, le procédé P s1 content les procédés P s2 et P s3. De même, le servce s 1 est responsable pour le chox du servce s x qu est assocé avec l actvté a 17. Cela veut dre que le procédé P sx est déployé par P s1. La fgure 23 llustre les procédés coopérants et leur déploement selon les dépances du chox de servces. La fgure llustre également la propagaton de l dentté du servce chos vers les servces dépant comme décrt dans l exemple c-dessus. 133

150 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces s x d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 s x a2 a13 a14 d4 d2 s x a5 a15 a16 a12 a18 a19 a20 a7 a4 d5 d3 Fg. 6.7 Le chox du servce s x qu exécute l actvté a 12 s 1 P s2 P s3 s x s 2 s 3 P sx P s1 s x s x La propagaton de l dentté du servce sx s x sx s 17 s 7 La sélecton des servces 134

151 6.4. Chox dynamque et décentralsé retardé Extenson de l approche par des consdératons d mplémentaton Le mécansme de chox dynamque et décentralsé des servces se penche sur un aspect partculer de l exécuton décentralsée d un procédé. La technque que nous avons développée garantt la synchronsaton entre les servces dépants par rapport à un servce dynamquement chos. La lmtaton prncpale de cette approche est le chox de certans servces ben avant leur nvocaton pour maîtrser les dffcultés de synchronsaton. Dans le reste de ce chaptre, nous développons une deuxème approche pour ce problème. Outre, cette lmtaton prncpale, pluseurs aspects du chox dynamque et décentralsé de servces sont à consdérer. L mplémentaton d une composton de servce se base sur un ensemble de crtères qu spécfent l nfrastructure sous-jacente. Dans le chaptre 4, nous avons judceusement dscuté ces crtères. Typquement, ls consdèrent les canaux de communcaton mplémentés par les servces qu exécutent les actvtés de connexon qu reçovent les données écrtes dans les canaux de communcaton. Même s ce type d mplémentaton est l approche prncpale adoptée par les mplémentatons actuelles [Kazhamakn et al.2006], elle n est pas la seule. L mplémentaton des canaux de communcaton peut se fare de pluseurs autres manères en révsant les crtères d exacttude d une composton [Strcker et al.1995]. L mplémentaton du canal de communcaton par le servce qu émet les messages est éventuellement une approche à l mplémentaton d une composton. Dans ce cas, les données envoyées sont stockées par le servce qu les envoe et le servce qu dot les recevor récupère de canal mplémenté par le servce expédteur. S la dernère est consdérée pour l mplémentaton du chox décentralsé de servces comme nous l avons présenté c-dessus, le mécansme n est pas oblgé de chosr un servce qu précède tous les servces dépants. Une donnée à envoyer peut être stockée le canal mplémenté par l expédteur et le servce récepteur, quand l est chos, peut venr chercher les données. 6.4 Chox dynamque et décentralsé retardé Selon l approche présentée dans la secton précédente, un servce est chos dynamquement avant son nvocaton. Il est à noter que la sélecton du servce est suve par le déploement du procédé coopérant que le servce chos dot exécuter. Cette approche a une lmtaton. Elle est lée à la soluton adoptée pour empêcher les problèmes de synchronsaton. En fat, un servce n est pas chos juste avant son nvocaton, l est chos à une étape de l exécuton qu permet de régler le problème de synchronsaton. Afn de maîtrser cette dffculté, nous avons développé une deuxème approche pour le chox dynamque et décentralsé de servces. Cette approche consdère le chox retardé sans chosr le servce dans une étape précédente. L approche générale consste à mplémenter une technque de synchronsaton explcte entre les servces qu dovent être synchronsés pour le chox du servce dépant. La méthode mplémentée assure la synchronsaton des servces dépants par rapport au servce chos. Comme nous l avons soulgné c-dessus, cette approche est basée sur une poltque par défaut qu spécfe qu un servce dot être chos avant son nvocaton. Dans des exécutons décentralsées plus sophstquées, les concepteurs peuvent également défnr des poltques addtonnelles qu dentfent des couples de servces explctement. Dans cette secton, nous donnons les détals de l approche du chox retardé des servces. Dans ce cas encore, les servces exécutent toujours des procédés coopérants déployés dynamquement. Pourtant, une opératon addtonnelle qu permet l échange des messages de synchronsaton est mplémentée au sen des procédés. Il est à noter que cette approche nécesste l échange de données qu ne sont pas les données prncpales du procédé. Nous tenons à soulgner que l dée centrale est toujours basée sur les procédés coopérants qu mplémentent ces échanges. Dans les travaux relatfs, les mêmes échanges ne sont pas mplémentées au sen 135

152 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces des procédés mas plutôt par des protocoles explctes. L exemple 24 suvant est smlare à ceux qu sont présentés c-dessus. Nous l utlsons pour donner une descrpton nformelle de la synchronsaton des procédés coopérants par le chox retardé de servces. Exemple 24 (La synchronsaton dans le chox retardé) La fgure 24 llustre un fragment qu content sx actvtés a 6, a 8, a 9, a 10, a 11, et a 17 qu nvoquent respectvement les servces s 6, s 8, s 9, s 10, s 11 et s 17. C est un cas extrême dans lequel chaque actvté est exécutée par un servce dfférent. Nous consdérons un autre cas extrême où tous ces servces sont chos dynamquement. Dans ce cas, le servce s 6 chost s 8 et s 10, et par la sute, le servce s 8 chost s 9, et, le servce s 10 chost le servce s 11. Jusqu c le chox dynamque et décentralsé n est pas changé. Mas, dans ce scénaro, le servce s 17 dot être chos dynamquement, mas pas dans une étape antéreure. Comme la relaton mnbnd exste entre s 10 et s 17, et, s 11 et s 17, s un de ces deux servces chost s 17, l dentté du servce chos dot être dffusé vers l autre servce dépant. Le problème essentel de cette approche est que les servces qu dovent être synchronsés sont choss dynamquement. En plus, les servces qu chosssent ces servces sont auss choss dynamquement. Dans ce cas, la synchronsaton se complque consdérablement. L dée centrale de l approche du chox retardé est la proposton d une technque de synchronsaton entre les servces concernés. d6 d1 a8 a9 a3 a6 a17 a10 a11 d0 a0 a1 d4 a2 a13 a14 d2 a12 a18 a19 a20 a5 a15 a16 a7 a4 d5 d3 Fg. 6.8 La synchronsaton des servces pour le chox dynamque des servces Pour formalser le chox dynamque retardé, nous proposons les concepts suvants. Défnton 5 (Servces concurrents) Un ensemble de servces concurrents est un ensemble E S S, E S = A B t.q. A = {s S a = actvty(s ), â j <a <a j où a j est l actvté nvoquée par le servce qu fat l objet du chox concurrent} et B = {s S a = actvty(s ), d E d, a = source(d) target(d)=a j }. Dans cette défnton, nous rappelons qu une actvté nommée â correspond au pont de dsjoncton correspondant (resp. conjoncton) d un pont de conjoncton (resp. dsjoncton). En outre E d est l ensemble de dépances de donnée. La défnton 5 donne une caractérsaton formelle des servces qu sont concernés par le chox dynamque retardé d un servce qu fat l objet d un 136

153 6.4. Chox dynamque et décentralsé retardé chox concurrent. Ces servces sont ceux qu exécutent les actvtés qu restent entre le pont de conjoncton qu précède l actvté en queston et le pont de dsjoncton (AND/OR-splt) correspondant. Cet ensemble nclut également les servces qu exécutent les actvtés qu sont les sources des dépances de données entrantes. Le chox dynamque du servce qu fat l objet du chox concurrent ne nécesste pas une synchronsaton complète entre toutes ces actvtés. Néanmons, les servces qu exécutent ces actvtés sont concernées par le processus de synchronsaton des servces qu ont des relatons mnbnd avec ce derner. La synchronsaton se fat par l échange de messages consécutfs entre les servces qu appartennent à l ensemble de servces concurrents. Il n est pas souhatable que tous les servces de l ensemble E S qu correspond au servce choss soent synchronsés ensemble. Pour chaque servce qu fat parte de cet ensemble, nous avons dentfé un ensemble de servces qu sont les actvtés cbles des dépances mnbnd. Notre technque consste à échanger les denttés des servces choss à travers les éléments de E S. L exemple 25 suvant détalle cette opératon pour l exemple que nous avons utlsé c-dessus. Exemple 25 (La synchronsaton des servces) Le fragment présenté dans la fgure 6.9 llustre la sélecton dynamque des servces et la dffuson d denttés par rapport à des dépances de synchronsaton. Les dépances rayées en vert llustrent les dépances de bnd entre les servces qu exécutent les actvtés sources et cbles. Quant aux dépances rouges pontllées, elles llustrent comment les denttés des servces choss sont propagées à travers les éléments de l ensemble de servces concurrents. Il est à noter que les dépances qu relent les actvtés sont une projecton des nteractons des servces sous-jacents nvoqués avec l exécuton de celles-c. a 8 a 9 a 6 a 17 a 10 a 11 Fg. 6.9 La synchronsaton mutuelle des servces dynamquement choss Nous soulgnons que les servces qu exécutent ces actvtés ont les mêmes denttés. Le servce s 6 chost les servces s 8 et s 10 pour l exécuton. En même temps, l dentté du servce s 8 est transmse au servce s 10, et, l dentté du servce s 10 est transmse vers le servce s 8. Ans, les servces s 8 et s 10 peuvent se synchronser dans l étape suvante. À son tour, le servce s 10 chost s 11, et, le servce s 8 chost s 9. Il est à noter que les servces s 8 et s 10 se connassent mutuellement. Le processus de synchronsaton contnue avec les échanges d dentté des servces suvants. Ans, l dentté du servce s 11 est dffusé vers s 8, et, l dentté du servce s 9 est dffusé vers s 10. Par la sute, c est le tour des servces s 9 et s 11 de se synchronser. L exemple 25 a llustré les couples de servces qu dovent se synchronser pour la sélecton du servce qu exécutent l actvté a 17. Chaque servce qu est mplqué dans la sélecton du 137

154 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces a 8 a 9 a 3 a 6 a 17 a 10 a 11 a 1 a 2 a 12 a 5 a 7 a 4 Fg Le chox retardé du servce s 12 nvoqué par l actvté a 12 servce cble dot échanger les denttés des servces qu l chost avec les servces concernés de l ensemble des servces concurrents. Outre les couples de servces qu échangent des messages de synchronsaton, les servces qu chosssent le servce qu exécute a 17 dovent explctement être synchronsés pour la sélecton de ce derner. En partant de ces prncpes, nous proposons les concepts suvants pour formalser les nteractons des servces concernés. Défnton 6 (Servces synchrones) Sot a z une actvté pour laquelle un servce est dynamquement chos. Un ensemble de servces S s = {s,..., s j } est dt synchrone pour un ensemble d actvtés A s s a, a j A s, a a j a j a, nb c = nb cj où nb c et nb cj sont les nombres de dépances de contrôle depus le pont de dsjoncton qu précède les actvtés de S s. S s nclut également les actvtés sources des dépances de données qu cblent l actvté du servce dynamquement chos et les dernères actvtés qu précèdent a z. Plus formellement, Ss d ={a k A ( d E d, source(d) = a k target(d) = a z ) ( c E c, source(d) = a k target(d) = a z )} La défnton 6 llustre les tuples de servces qu dovent échanger des messages de synchronsaton qu ncluent les denttés des servces qu ls chosssent. Nous donnons un exemple de motvaton pour les servces synchrones dans l exemple 26. Il est à noter que les servces qu peuvent être choss sans procéder à un processus de synchronsaton sont ceux qu ne font pas l objet de chox concurrent. L dentfcaton des couples de servces synchrones se fat statquement pant l étape de concepton du procédé pant laquelle les concepteurs défnssent également les poltques du flux d nformaton. Exemple 26 (Identfcaton et échanges des servces synchrones) La fgure 6.10 llustre un fragment de procédé smplfé que nous avons précédemment utlsé. Il s agt du fragment qu commence avec l actvté a 1 et se termne a 12. Nous avons exclu les dépances de données. Le servce qu dot être dynamquement chos est s 12. Nous allons l utlser pour montrer les échanges de messages entre les servces. Nous magnons le cas, le plus complqué, dans lequel chaque actvté nvoque un servce dfférent. Les 138

155 6.4. Chox dynamque et décentralsé retardé servces nvoqués ont les mêmes denttés que les actvtés. En conséquence, les servces sont nommés s 1,..., s 17. Le servce s 12 est celu qu dot être dynamquement chos par les servces s 7 et s 17. Le pont de dsjoncton correspondant qu précède a 12 est l actvté a 1. Le servce s 1 nvoqué par a 1 chost dynamquement les servces qu exécutent respectvement s 2 et s 3 qu nvoquent respectvement a 2 et a 3. Les servces s 2 et s 3 consttuent le premer tuple de servces synchrones, ce derner nommé cs 1 = {s 2, s 3 }. Les éléments de l ensemble de serves synchrones dovent se connaître pour échanger les denttés des servces qu ls chosssent. La fgure 6.11 llustre cette opératon de synchronsaton. Le servce s 1 passe l dentté s 2 au servce s 3, et de même, passe l dentté du servce s 3 au servce s 2. Nous soulgnons auss que les nteractons llustrées dans cette fgure se réfèrent aux nteractons des servces sous-jacents nvoqués par ces actvtés. a 8 a 9 a 3 a 6 a 17 a 10 a 11 s 2 a 1 s 3 a 2 a 12 a 5 a 7 a 4 Fg La synchronsaton des servces s 2 et s 3 Le servce s 2 chos les servces s 4 et s 5. De même, le servce s 3 chost s 6. Ces tros servces s 4, s 5 et s 6 consttuent le deuxème tuple de servces synchrones, cp 2 = {s 4, s 5, s 6 }. Afn de permettre la synchronsaton des servces choss dans l étape prochane du processus de synchronsaton, les servces s 2 et s 3 échangent les denttés des servces choss et propagent les denttés vers les servces concernés. La fgure 6.12 llustre ces nteractons sous forme de dépances qu lent les actvtés. Les nteractons sont examnées en deux étapes. La premère nteracton a leu entre les servces s 2 et s 3 pour échanger les denttés des serves qu ls chosssent. Dans la deuxème étape, les denttés reçues sont propagées vers les servces qu sont choss par le servce même. À leur tour, les servces s 4 et s 5 chosssent le servce s 7 par le processus de synchronsaton. Le servce s 6 chost les servces s 8 et s 10 par rapport à ses dépances de contrôles sortantes. Ans, le trosème tuple de servce synchrones cp 3 = {s 7, s 8, s 10 }. Les échanges de synchronsaton de ces serves sont llustrés dans la fgure Les servces s 4, s 5 et s 6 qu connassent les denttés échangent les denttés des servces qu ls chosssent. Par la sute, les denttés échangées sont propagées vers les servces choss dans l étape précédente. Ans, le servce s 6 envoe l dentté de s 8 et s 10 vers ses servces synchrones qu sont s 4 et s 5. Ces derners envoent l dentté du servce s 7 vers s 6. Il est à noter que les servces s 4 et s 5 chosssent le servce s 7. En conséquence, c est seulement le servce s 4 qu envoe l dentté du servce s 7 vers s 6. Par la sute, le servce s 8 chost le servce s 9 et le servce s 10 chost s 11. Ces deux servces choss consttuent le tuple cp 4 avec le servce s 7, cp 4 = {s 7, s 9, s 11 }. La fgure 6.14 llustre cette étape 139

156 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces s 5, s 4 2 a 8 a 9 a 3 a 6 a 17 a 10 a 11 a 1 s6 1 s5, s4 a 2 2 s4, s 6 a 5 a 12 a 7 s 5, s 6 a 4 Fg La synchronsaton des servces s 4, s 5 et s 6 s 7 2 a 8 a 9 a 3 a 6 a 17 s 7 2 a 10 a 11 a 1 a 2 s 8, s s 8, s 10 s7 a 12 a 5 s 8, s 10 2 a 7 a 4 Fg La synchronsaton des servces s 4, s 5 et s 6 du processus de synchronsaton. Le servce s 8 envoe l dentté du servce s 9 vers le servce s 7. De même, le servce s 10 envoe l dentté du servce s 11. L dentté du servce s 7 est transférée vers le servce s 9 et s 11. Le servce s 7 est nclu dans cet ensemble comme l est un des servces qu est responsable du chox du servce s 12. Les servces s 9 et s 11 consttuent un autre ensemble de servces synchrones pour le chox du servce s 17. Le derner ensemble de servces synchrones cp 5 = {s 7, s 17 }. La fgure 6.15 llustre les dépances qu caractérsent les nteractons des servces s 7, s 9 et s 11 pour échanger les denttés du servce s 7 avec le servce s 17 et l dentté du servce s 17 avec le servce s 7. Il est à noter que les servces s 7 et s 17 sont les servces responsables pour le chox du servce s 12. Le processus de synchronsaton a pour but d échanger les denttés des servces qu précédent un servce par rapport aux dépances de sélecton. Les échanges ntermédares ne concernent pas la sélecton du servce s 12 drectement. Leur but est de permettre l échange des denttés des 140

157 6.4. Chox dynamque et décentralsé retardé s 7 a 8 a 9 a 3 a 6 a 17 a 10 a 11 s 7 a 1 a 2 s 9 a 12 a 5 s 11 a 7 a 4 Fg La synchronsaton des servces s 7, s 8 et s 10 s 7 a 8 a 9 a 3 a 6 a 17 a 10 a 11 a 1 s 17 s 7 a 2 a 12 a 5 a 7 a 4 Fg La synchronsaton des servces s 7, s 9 et s 11 servces ntermédares qu précédent s Synchronsaton explcte de servces La deuxème approche qu porte sur le chox dynamque et décentralsé de servces assure la connassance des derners servces les uns avec les autres pour le chox du servce concerné. Pourtant, le mécansme n mpose pas une synchronsaton explcte sur l nstance précse du servce à chosr. Dans l exemple 26, le processus de synchronsaton suppose que les serves qu exécutent les actvtés a 7, a 9 et a 11 aent les denttés des uns des autres pour pouvor fare les échanges nécessares pour le chox du servce s 12 qu exécutera l actvté a 12. À ce pont de l exécuton, la synchronsaton de ces tros servces n est pas une opératon ntutve. Ce problème peut être résolu de pluseurs autres manères. Nous avons mplémenté une soluton smple pour maîtrser ce problème. Le servce qu a la plus pette dentté est responsable pour la sélecton 141

158 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces et la propagaton de l dentté du servce concerné aux autres servces synchrones. Ce servce est également responsable pour le déploement du procédé coopérant du servce chos. 6.5 Implémentaton du chox dynamque et décentralsé dans WS-BPEL Dans les chaptres précédents, nous avons soulgné que l exécuton décentralsée mplémentée par les procédés coopérants état motvée essentellement pas les efforts de standardsaton qu permettaent l échange des spécfcaton standardsées telles que WS-BPEL. Une des rasons qu a motvé l extenson de la même approche vers le chox dynamque et décentralsé des servces est certanement la faclté de l mplémentaton de l approche en utlsant WS-BPEL [Schuler et al.2004] [Pautasso and Alonso2005]. Ce détal technque est mportant pour explquer l ntérêt du chox dynamque. La fgure 6.16 llustre un exemple de code qu porte sur l encodage de chox dynamque en WS-BPEL. L exemple prs de [Pautasso and Alonso2005] llustre un exemple d mplémentaton. <process xmlns=" name="asyncechoservce" targetnamespace="urn:asyncecho:servce" xmlns:ths="urn:asyncecho:servce" suppressjonfalure="no" enableinstancecompensaton="no" abstractprocess="no"> <partnerlnks> < name="caller" partnerlnktype="ths:echoplt" myrole="servce" partnerrole="clent"/> </partnerlnks> <varables> < name="echomessage" messagetype="ths:echomessage"/> </varables> <sequence> <receve name="echoreceve" partnerlnk="caller" porttype="ths:echoservce" operaton="echo" varable="echomessage" createinstance="yes"/> <assgn> <copy> <from varable="echomessage" part="replyto"/> <to partnerlnk="caller"/> </copy> </assgn> <nvoke name="echoreply" partnerlnk="caller" porttype="ths:echoclent" operaton="echocallback" nputvarable="echomessage"/> </sequence> Fg Implémentaton du chox dynamque dans WS-BPEL En effet la dynamcté supportée par WS-BPEL consste à manpuler les -ponts des servces en fasant un changement de varable classque. Les -ponts peuvent être dentfés en utlsant le standard WS-Adressng. L actvté receve reçot une donnée qu content le -pont d un servce. Cette donnée remplace le -pont du servce nvoqué par l actvté nvoke prochan. Le remplacement se fat par l exécuton de l actvté assgn. 6.6 Synthèse L approche de l exécuton décentralsée présentée dans les deux chaptres précédents détalle la producton des procédés coopérants à partr d une spécfcaton centralsée. Par rapport à 142

159 6.6. Synthèse ces contrbutons qu consdèrent le déploement centralsé et statque des procédés, l approche qu a été présentée dans ce chaptre permet l explotaton de technques de composton dynamque de servces. L expérmentaton des contrbutons précédentes nous a perms de trater des exemples qu n auraent pas pu être drectement mplémentées avec l approche ntale qu consdère le déploement centralsé. Cepant, les problèmes dentfés ne font pas appel à des technques spécfques à la producton des procédés coopérants. On peut donc envsager d étre une telle démarche à d autres dmensons. Dans ce chaptre, nous nous sommes attachés à dentfer les besons en termes de dynamcté de compostons décentralsées en nous postonnant par rapport au modèle de référence d une part, et à l étude de standards ou d outls exstants d autre part. L objectf de ce traval étant l mplémentaton d exécutons décentralsées destnées à l évaluaton d une méthodologe ou à sa démonstraton, nous avons proposé deux approches à la composton dynamque et décentralsée. Les méthodologes et les envronnements de décentralsaton ont pour objectf d établr les nteractons entre les servces composés. Cepant, ces envronnements se focalsent sur la descrpton de solutons d nteractons et n offrent pas de proposton satsfasante du pont de vue de la dynamcté. L mplémentaton est donc rédute à tester la fasablté d nteractons au moyen de méthodes non exhaustves basées sur des jeux de tests. L mplémentaton d une soluton exprmée dans les formalsmes habtuellement proposés entraîne souvent des dérves mportantes lées à une mauvase nterprétaton des exgences ntales en termes de décentralsaton. L mplémentaton du chox dynamque et décentralsée présente une soluton pratque dans le contexte AOS. De plus, cette technque permet d utlser la spécfcaton produte dans la phase d exécuton. Cepant, leur complexté de mse en œuvre est un fren qu empêche actuellement leur utlsaton de manère généralsée. Notre approche consdère deux méthodes de chox dynamque et décentralsé. En partant des exgences ntutves des procédés méters, nous avons une premère approche qu supporte l exécuton décentralsée du procédé par le chox dynamque et décentralsé de servces. Dans ce mode d exécuton, un servce est chos pour le procédé avant sa premère utlsaton lors de l exécuton. Ce mode de chox engre des problèmes de sélecton concurrente et éventuellement des problèmes de synchronsaton entre les éléments choss d une manère concurrente. Nous avons développé une méthodologe de sélecton dynamque et décentralsée qu empêche les problèmes lés au chox concurrent en permettant à un servce d être chos avant son exécuton. Cette méthodologe consste à dentfer des couples de servces dont l un chost l autre. Une lmtaton de cette approche est que la sélecton n est pas toujours fate avant l nvocaton du servce afn d empêcher les problèmes de synchronsaton. Dans ce contexte, nous avons développé une deuxème approche qu maîtrse la lmtaton ntrodute par celle-c. Avec la deuxème approche, un servce est chos juste avant son exécuton grâce à l échange des messages de synchronsaton entre les servces qu le précédent sur les chemns allant vers celu-c. Les opératons de synchronsaton entre les servces sont mplémentées comme des fragments de procédés concurrents aux procédés coopérants prncpaux exécutés par les servces. Dans les deux cas, nous nous plaçons dans une optque de chox dynamque et décentralsé de servces [Yldz and Godart2007f] [Yldz and Godart2007e] [Yldz and Godart2007b]. La méthodologe de déploement dynamque et décentralsé explote les possbltés de l approche exécuton décentralsée par des procédés coopérants dans un contexte plus applcatf en maîtrsant les dffcultés lées. Cepant, l exste un problème lé à l approche dès qu l s agt de défnr des restrctons de déploement sophstquées qu manpulent de gros procédés : complexté des modèles, structuraton des mémores de connexon, dffculté d nterprétaton des restrctons etc. 143

160 Chaptre 6. L mplémentaton du chox dynamque et décentralsé des servces 144

161 Chaptre 7 Mse en œuvre Sommare 7.1 Introducton L mplémentaton de l échangeablté des procédés coopérants Implémentaton des servces La producton des procédés coopérants avec WS-BPEL Synthèse Introducton Dans ce chaptre, nous présentons la plate-forme d mplémentaton des contrbutons présentées dans les chaptres antéreurs. L dée clé des exécutons décentralsées est la possblté d échangeablté d une spécfcaton de procédé entre les dfférentes organsatons. Dans un premer temps, cette approche nécesste d une plate-forme qu permet l échangeablté des spécfcatons. Les structures de données et les algorthmes présentés précédemment précsent les détals de la producton des procédés coopérants d une manère générque. Dans un deuxème temps, cette parte de notre traval nécesste une mplémentaton concrète pour montrer la fasablté de l approche. En conséquence, la valdaton logcelle de nos contrbutons peut être examnée en deux parte ndépantes mas complémentares. 7.2 L mplémentaton de l échangeablté des procédés coopérants Le déploement d un procédé vers un servce par un autre servce ou d un clent nécesste la présence d un moteur d exécuton du procédé mplémenté par le servce qu reçot et qu exécutera le procédé. Dans le contexte des applcatons modernes, la présence d un moteur d exécuton mplémenté au delà de l nterface du servce est une hypothèse assez rasonnable. Le moteur d exécuton peut nstancer un procédé standard tel que WS-BPEL ou ben le convertr en un autre type de procédé qu l peut exécuter. La fgure 7.1 llustre une vue d ensemble de l mplémentaton d un servce qu peut supporter notre approche dans sa généralté. Ce module est nommé SDS (Servce wth Decentralzed Support). Comme nous l avons ndqué dans les chaptres précédents, un servce est une applcaton logcelle qu est accessble aux clents sur le Web par une nterface. Le déploement d un 145

162 Chaptre 7. Mse en œuvre Interface La queue d entrée Fltres La queue de sorte Fchers WSDL Adapteur Trateur de messages Les nstances des procédés WS-BPEL Autres Servces Plans de déploement Etas des procédés Données Moteur Admnstraton Alarmes Montorage Applcaton Fle nterne Autres Servces JMS, REST, POJO ActveBPEL Envronnements Xpath, Xquery Interface Contaneur (Servce Implémentaton) Fg. 7.1 Vue d ensemble de l mplémentaton d un servce procédé à exécuter se fat par des appels aux méthodes d admnstraton du moteur d exécuton qu font parte de l nterface de servce. Les opératons d admnstraton d un moteur d exécuton permettent la geston des procédés telles que l ntalsaton d un modèle dans le moteur, la survellance des nstances ou leur suspensons. Les opératons d admnstraton peuvent être évoquées localement et elles ne sont pas accessbles par les clents va le Web. L mplémentaton de ces opératons comme les opératons accessbles du servce permet leur nvocatons par les clents va le Web. Cette mplémentaton est une soluton smple et élégante à l échangeablté des procédés entre les servces. Cette archtecture de servce consdère un moteur d exécuton et l accessblté des opératons de l admnstraton du moteur comme des servces Web. Il est à noter qu on peut consdérer l mplémentaton d autres modules logcels secondares pour supporter les deux premères fonctonnaltés prncpales. L mplémentaton logcelle que nous avons réalsée utlse le moteur ActveBPEL pour exécuter les procédés. La rason de ce chox est essentellement motvée par le fat que le moteur est une applcaton open-source clarement documentée. Le moteur chos fournt un certan nombre de fonctonnaltés caractérstques des moteurs de workflow telles que le déploement des procédés WS-BPEL, le montorage des procédés déployés ou leur vsualsatons. L admnstraton du moteur ActveBPEL se fat par ActveBPEL Engne Admnstraton Interface (API). La fgure 7.2 llustre les composants prncpaux du moteur avec ceux que nous avons travallés en vue d mplémenter les opératons d admnstraton. Dans nos premères expérmentatons, nous avons réalsé une mplémentaton qu transforme les opératons d admnstraton de ActveBPEL. Pant ce temps, le producteur d ActveBPEL a ntrodut ActveBPEL Engne Admnstraton Interface (API). Le code c-dessous llustre un fragment de WSDL qu content l mplémentaton des opéra- 146

163 7.2. L mplémentaton de l échangeablté des procédés coopérants Fg. 7.2 Vue d nsemble de l ActveBPEL et les modules que nous avons étus tons d admnstraton dans l nterface de servce. Nous attrons l attenton sur la défnton des varables des opératons d admnstraton dans l entête du document WSDL et leur défntons dans les opératons dans le reste du fcher WSDL. <?xml verson="1.0" encodng="utf-8"?> <wsdl:defntons targetnamespace="urn:aeadmnservces" xmlns:apachesoap=" xmlns:mpl="urn:aeadmnservces" xmlns:soapenc=" xmlns:tns1=" xmlns:tns2=" xmlns:tns3=" xmlns:tns4=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" <wsdl:types> <schema targetnamespace=" xmlns=" <mport namespace=" <complextype name="aeexcepton"> <sequence> <element name="nfo" nllable="true" type="xsd:strng"/> </sequence> </complextype> </schema> <schema targetnamespace=" xmlns=" <mport namespace=" <mport namespace=" <complextype name="aebusnessprocessexcepton"> <complexcontent> <extenson base="tns1:aeexcepton"> <sequence/> </extenson> </complexcontent> </complextype> 147

164 Chaptre 7. Mse en œuvre </schema> <schema targetnamespace=" xmlns=" xmlns:tns=" <mport namespace=" <mport namespace=" <mport namespace="urn:aeadmnservces"/> <complextype name="aelstngflter"> <sequence> <element name="lststart" type="xsd:nt"/> <element name="maxreturn" type="xsd:nt"/> </sequence> </complextype> <complextype name="aeprocessflter"> <complexcontent> <extenson base="tns:aelstngflter"> <sequence> <element name="processcompleteend" nllable="true" type="xsd:datetme"/> <element name="processcompletestart" nllable="true" type="xsd:datetme"/> <element name="processcreateend" nllable="true" type="xsd:datetme"/> <element name="processcreatestart" nllable="true" type="xsd:datetme"/> <element name="processname" nllable="true" type="xsd:qname"/> <element name="processstate" type="xsd:nt"/> </sequence> </extenson> </complexcontent> </complextype> <complextype name="aeprocessinstancedetal"> <sequence> <element name="ed" nllable="true" type="xsd:datetme"/> <element name="name" nllable="true" type="xsd:qname"/> <element name="processid" type="xsd:long"/> <element name="started" nllable="true" type="xsd:datetme"/> <element name="state" type="xsd:nt"/> <element name="statestrng" nllable="true" type="xsd:strng"/> </sequence> </complextype> <complextype name="aeprocesslstresult"> <sequence> <element name="totalrowcount" type="xsd:nt"/> <element name="completerowcount" type="xsd:boolean"/> <element name="rowdetals" nllable="true" type="mpl:aeprocessinstancedetalarray"/> <element name="empty" type="xsd:boolean"/> </sequence> </complextype> </schema> <schema targetnamespace=" vebpel.org" xmlns=" <mport namespace=" <mport namespace=" <mport namespace="urn:aeadmnservces"/> <complextype name="aebreakpontinstancedetal"> <sequence> <element name="processname" nllable="true" type="xsd:qname"/> <element name="nodepath" nllable="true" type="xsd:strng"/> </sequence> </complextype> <complextype name="aebreakpontlst"> 148

165 7.2. L mplémentaton de l échangeablté des procédés coopérants <sequence>... <wsdl:porttype name="iaebpeladmn"> <wsdl:operaton name="getconfguraton"> <wsdl:nput message="mpl:getconfguratonrequest" name="getconfguratonrequest"/> <wsdl:output message="mpl:getconfguratonresponse" name="getconfguratonresponse"/> <wsdl:fault message="mpl:aeexcepton" name="aeexcepton"/> </wsdl:operaton> <wsdl:operaton name="setconfguraton" parameterorder="axmlstrng"> <wsdl:nput message="mpl:setconfguratonrequest" name="setconfguratonrequest"/> <wsdl:output message="mpl:setconfguratonresponse" name="setconfguratonresponse"/> <wsdl:fault message="mpl:aeexcepton" name="aeexcepton"/> </wsdl:operaton> <wsdl:operaton name="suspprocess" parameterorder="apd"> <wsdl:nput message="mpl:suspprocessrequest" name="suspprocessrequest"/> <wsdl:output message="mpl:suspprocessresponse" name="suspprocessresponse"/> <wsdl:fault message="mpl:aebusnessprocessexcepton" name="aebusnessprocessexcepton"/> </wsdl:operaton> <wsdl:operaton name="resumeprocess" parameterorder="apd"> <wsdl:nput message="mpl:resumeprocessrequest" name="resumeprocessrequest"/> <wsdl:output message="mpl:resumeprocessresponse" name="resumeprocessresponse"/> <wsdl:fault message="mpl:aebusnessprocessexcepton" name="aebusnessprocessexcepton"/> </wsdl:operaton> <wsdl:operaton name="resumeprocessobject" parameterorder="apd alocaton"> <wsdl:nput message="mpl:resumeprocessobjectrequest" name="resumeprocessobjectrequest"/> <wsdl:output message="mpl:resumeprocessobjectresponse" name="resumeprocessobjectresponse"/> <wsdl:fault message="mpl:aebusnessprocessexcepton" name="aebusnessprocessexcepton"/> </wsdl:operaton> <wsdl:operaton name="termnateprocess" parameterorder="apd"> <wsdl:nput message="mpl:termnateprocessrequest" name="termnateprocessrequest"/> <wsdl:output message="mpl:termnateprocessresponse" name="termnateprocessresponse"/> <wsdl:fault message="mpl:aebusnessprocessexcepton" name="aebusnessprocessexcepton"/> </wsdl:operaton> La spécfcaton WSDL c-dessus est l élément prncpal de module SDS de l mplémentaton. Nous avons basé notre traval sur la faclté de réalsaton des exécutons décentralsées avec des procédés coopérants échangés entre les servces composés. Cette réalsaton elle-même est basée sur la possblté de réalsaton des servces qu sont capables de recevor et d exécuter des procédés. Comme l mplémentaton c-dessus le démontre cette réalsaton est relatvement smple et consste en une mplémentaton typque de servce. Il est à noter que les procédés coopérants ncluent des actvtés qu nvoquent les opératons décrtes dans cette nterface. Un procédé WS-BPEL est conçu avec un fcher WSDL qu reçot les nvocatons entrantes. En des procédés coopérants, nous fournssons les fchers WSDL correspondants. L mplémentaton des opératons d admnstraton de ActveBPEL consdère également le déploement des fchers WSDL. Les fchers déployés sont gérés dans un pool dynamque qu les mantent. La verson 149

166 Chaptre 7. Mse en œuvre 3.1 de ActveBPEL supporte l accès aux opératons d admnstratons sur le Web. Pourtant le déploement n est pas une opératon supportée. Outre les problèmes d mplémentaton des opératons d admnstraton, une deuxème dffculté est lée à la geston des messages entrants et sortants. L mplémentaton des fles consste à fare des chox relatfs au support matérel sous-jacent. Nous avons mplémenté un fle commune à tous les fchers WSDLs, la lecture y est arbtrare. Cette consdératon archtecturale peut causer des problèmes de performance parce que la talle de la fle est proportonnelle au nombre de procédés nstancés. Une autre détal de l archtecture logcelle porte sur l nteracton du moteur d exécuton avec l applcaton qu mplémente le servce. Les actvtés orgnales de la spécfcaton sont structurées dans les procédés exécutés par le moteur mplémenté pour le servce auxquels elles se référe. Dans ce cas, les actvtés exécutées par le procédé du servce se référent aux opératons du servce même. Cette stuaton cause l établssement d une connexon vers l extéreur qu peut surcharger les fles de communcatons. Pour empêcher ces connexons non-souhatables, le module de tratement des nvocatons reçues modfe le contenu des actvtés de telle sorte que l actvté évoque l applcaton nterne qu mplémente le servce Implémentaton des servces Dans cette secton, nous détallons certans aspects de l mplémentaton des réalsatons de servces que nous avons utlsés pour nos expérmentatons. Le moteur ActveBPEL est le composant prncpal de l mplémentaton. Le moteur est mplémenté au dessus d un serveur Web. L mplémentaton de ce derner consdère un type de protocole qu l utlse pour communquer avec ses clents. Typquement, on peut consdérer deux types de protocoles SOAP-over-HTTP et SOAP-over-JMS pour ce propos. Pour procéder aux expérmentatons, nous avons mplémenté des servces qu emploent ces deux types de protocoles. Le premer protocole, SOAP-over-HTTP, est un protocole synchrone alors que l exécuton décentralsée consdère des communcatons asynchrones. Les messages un-drectonnel peuvent être échangés en envoyant des messages vdes aux expédteurs des messages. Quand un servce Web est nvoqué en utlsant HTTP, le servce est mplémenté comme un servlet contenu dans un contaner servlet. Les servlets sont conçus pour être mplémentés avec des messages synchrones de type request-response. Le message de réponse ne peut pas être envoyé tant que le tratement de message request n est pas fn. En conséquence, un clent qu veut nvoquer un servce est bloqué lorsqu l y a un autre clent qu l a déjà nvoqué et n a pas reçu de réponse. ActveBPEL mantent un pool ndépant de servlet. ActveBPEL envoe un message vde quand l reçot un message et la demande reçue est mse dans le canal nterne pour être transféré au servlet. Dans le deuxème type d mplémentaton, on a consdéré SOAP-over-JMS. Quand un servce est nvoqué en utlsant JMS (Java Messagng Servce), le servce est mplémenté comme un MDB (Message Drven Bean). Ce derner est nclu dans un EJB (Enterprse Java Bean). Les EJB ont un seul canal et également un seul processus qu trate ce canal. Le fonctonnement des EJB est quasment semblable à l mplémentaton d un servlet avec un pool de talle varable. Même s les deux mplémentatons sont relatvement smlares, les servlets analysent les messages reçus ce qu peut consttuer un problème de performance s la talle et le nombre des messages devennent mportant. 7.3 La producton des procédés coopérants avec WS-BPEL Dans cette secton, nous dscutons les détales d mplémentaton de la producton des procédés coopérants en utlsant la spécfcaton WS-BPEL. Cette parte de l mplémentaton est nommée PPP (Peer Process Producer). En langage WS-BPEL, un procédé peut être exprmé 150

167 7.3. La producton des procédés coopérants avec WS-BPEL Lancement de PPP Exécuton des tâches du système (autentfcaton...) Lancement des nterfaces graphques Sase des poltques du flux d nformaton Concepton du procédé Vérfcaton et plannfcaton de l exécuton Producton et déploement des procédés coopérants Fg. 7.3 Vue d ensemble du module PPP sous des formes dfférentes. Cec est lé à l utlsaton complémentares des actvtés structurées (flow, sequence, swtch) et lnk de la spécfcaton WS-BPEL [Rechert et al.2004]. Dans [Wohed et al.2003] [Bergholtz et al.2004] présentent des frameworks pour passer d une spécfcaton WS-BPEL à une autre spécfcaton plus conceptuelle telle que les patrons de workflow. Nous avons essentellement utlsé les analyses présentées dans ces travaux. La producton des procédés coopérants se fat en pluseurs étapes comme explqué dans les chaptres précédents. Ic nous allons présenter les éléments prncpaux de l mplémentaton. La fgure 7.3 llustre la vue d ensemble de l utlsaton de l ntalsaton du module PPP alors que la fgure 7.3 llustre ses classes prncpales. Les classes mplémentées correspondent aux concepts utlsés dans les chaptres précédents. L mplémentaton du module PPP se base sur l utlsaton de l API JDOM de Java qu est conçu pour la manpulaton des fchers XML. Ce chox est en parte ntutf. Parce que la spécfcaton d un procédé WS-BPEL est analogue à une spécfcaton XML. JDOM est une API du langage 151

168 Chaptre 7. Mse en œuvre Process Element * * Depency * * 1 Fragment -Actvtes : Actvty +set() +get() +getdsjoncton() : Actvty +getjoncton() : Actvty Actvty Data -Input : Data «bnd»-output : Data -Transton : Data * * 2 Data Control Exted Sets AND OR * Informaton Restrctons Preset Postset * Ext. Preset Ext. Postset Servces Conceptor Routng Verfcaton JDOM Converter «uses» Process Producer Polcy verfer Path fnder Pre connector Post connector Structurer Fg. 7.4 Les classes prncpales du module PPP 152

169 7.3. La producton des procédés coopérants avec WS-BPEL Java développée ndépamment de Sun Mcrosystems. Elle permet de manpuler des donnés XML plus smplement qu avec les API classques. Son utlsaton est pratque pour tout développeur Java et repose sur les API XML de Sun. JDOM utlse DOM pour manpuler les éléments d un Model Objet de Document spécfque crée grâce à un constructeur basé sur SAX. On peut donc construre des documents, navguer dans leur structure, ajouter, modfer, ou supprmer sot des éléments sot du contenu. DOM est l acronyme de Document Object Model. C est une spécfcaton du W3C pour proposer une API qu permet de modélser, de parcourr et de manpuler un document XML. Le prncpal rôle de DOM est de fournr une représentaton mémore d un document XML sous la forme d un arbre d objets et d en permettre la manpulaton (recherche d un élément précs, mse à jour d élément trouvé...). À partr de cette représentaton (le modèle), DOM propose de parcourr le document mas auss de pouvor le modfer. Ce derner aspect est l un des aspect les plus ntéressant de DOM pour la producton des procédés coopérants. DOM est défn pour être ndépant du langage dans lequel l sera mplémenté. DOM n est qu une spécfcaton qu pour être utlsée dot être mplémentée par un édteur ters. DOM n est donc pas spécfque à Java. SAX est l acronyme de Smple API for XML. Ce type de parseur utlse des événements pour ploter le tratement d un fcher XML. Un objet (nommé handler en anglas) dot mplémenter des méthodes partculères défnes dans une nterface de l API pour fournr les manpulatons à mplémenter : selon les événements, le parseur appelle ces méthodes. La premère utlsaton de JDOM porte sur l extracton des dépances nécessares pour la producton des procédés coopérants. La premère opératon de JDOM est de créer un objet de type org.w3c.dom.document à partr de la spécfcaton WS-BPEL à décentralser. Tant que l ntégralté du document n a pas été analysée et ajoutée dans la structure arborescente à ce nveau supéreur par rapport à l élément racne du document XML, les données du fcher d entrée ne se trouvent pas dans un état utlsable. En fat, comme le standard DOM ne spécfe pas de méthode pour obtenr l objet Document, l exste pluseurs méthodes à cette fn. Les algorthmes prncpaux que nous avons mplémentés sont présentés dans l annexe A. Ce fcher qu content les dépances de contrôle, de donnée, et d étue ans que les ensembles qu correspondent aux actvtés dépantes, est utlsé pour la producton des procédés coopérants. C-dessous, nous donnons quelques lgnes de code concernant la manpulaton des fcher. mport org.apache.xerces.parsers.domparser; publc class WSBPELDOM { publc statc vod man( Strng [] args ) throws Excepton { WSBPELDOM parser = new WSBPELDOM(); parser.parse("ws-bpel-sample.xml"); Document document = parser.getdocument(); } } Pour extrare les dépances nécessares à la producton des procédés, nous récupérons d abord l élément racne du document ws-bpel-sample.xml, va la méthode getrootelement() applquée au noeud de type Document précédemment défn. Ensute, nous défnssons un noeud de type Element, équvalent à une collecton Java, qu regroupe tous les éléments dont le type est ttre, va la méthode getelementsbytagname( Actvty ). Enfn, nous térons sur cette lste afn de récupérer la valeur de chacun des noeuds de type Element : en effet la structure hérarchque du DOM mpose de devor récupérer le contenu textuel d un élément, non à partr de l élément lu-même, mas à partr du noeud fls de l élément. La premère étape (récupératon du noeud fls de l élément <ttre> se fat grâce à la méthode getfrstchld(), tands que la récupératon de la valeur textuelle se fat en utlsant la méthode getnodevalue().voc le code correspondant aux étapes que l on vent de décrre : 153

170 Chaptre 7. Mse en œuvre... Element catalogue = document.getrootelement(); NodeLst ttres = ws-bpel-sample.getelementsbytagname("actvty"); whle(ter.hasnext()){ LnkedLst <Element> = (ter.next()).gettexttrm() } Un autre aspect mportant est l ntalsaton des contenus des messages échangés. Dans un premer temps, cet aspect concerne l échange du contrôle entre deux actvtés lées par une dépance de contrôle. Dans un deuxème temps cec concerne une dépance de donnée. Nous ne dscutons pas les nteractons qu mplémentent les dépances étues car elles sont des combnasons des nteractons de contrôle et de donnée. <scope name="a1a2control-scope"> <faulthandlers> <catch faultname="jfns:jonfalure"> <nvoke partnerlnk="a1a2" porttype="apnsf:op1" operaton="a1a2lnk" nputvarable="falseandcorrel"/> </catch> </faulthandlers> <nvoke name="a1a2control" suppressjonfalure="no" partnerlnk="a1a2" porttype="apnsf:op2" operaton="a1a2lnk" nputvarable="trueandcorrel"> <target lnkname="c"/> </nvoke> </scope> La récepton du message de contrôle dans le procédé coopérant qu exécute l actvté de connexon de lecture est llustré dans le code suvant. <receve name="receve1" partnerlnk="a1a2" porttype="apnsf:op2" operaton="a1a2lnk" varable="statusa1a2" createinstance="yes"> <correlatons> <correlaton set="name" ntate="yes"/> </correlatons> <source lnkname="op1" transtoncondton= "bpws:getvarabledata( statusa1a2, status )"/> </receve> Dans l exemple suvant, nous décrvons l ntalsaton de deux actvtés de connexon qu échangent une donnée de procédé. Dans le code c-dessus, on décrt l mplémentaton d une dépance de donnée entre une actvté de type assgn et une de type reply. Nous les appelons les opératons op1 et op2. Il est à noter que ce code ne consdère pas la dépance de contrôle entre ces deux actvtés. 154 <scope> <faulthandlers> <catch faultname="jfns:jonfalure"> <nvoke partnerlnk="a1a3" porttype="lns:op1" operaton="a3a1data" nputvarable="falseandcorrel" /> </catch> </faulthandlers> <sequence suppressjonfalure="no"> <target lnkname="data-assgn-to-man"/> <assgn> <copy> <from><status xmlns="" xs:type="xsd:boolean">true</status></from> <to varable="v1" part="status"/> </copy> <copy> <from varable="trueandcorrel" part="name"/> <to varable="v1" part="name"/> </copy> <copy> <from varable="v2" part="accept"/> <to varable="v1" part="accept"/></copy> </assgn> <nvoke partnerlnk="n1n3" porttype="lns:op2" operaton="n3n1data" nputvarable="v1" /> </sequence> </scope>

171 7.4. Synthèse Le code suvant décrt l échange de données de la part du servce qu exécute le procédé qu nclut l actvté reply. Nous soulgnons que ce code nclut essentellement une actvté receve qu correspond à l actvté de type a r dans les algorthmes générques des chaptres précédents et l actvté reply placée dans ce code. <receve name="n3n1data" partnerlnk="n1n3" porttype="lns:op2" operaton="n3n1data" varable="v1n3" createinstance="yes"> <correlatons> <correlaton set="name" ntate="yes"/> </correlatons> <source lnkname="data-assgn-to-reply" transtoncondton= "bpws:getvarabledata( v1n3, status )"/> </receve> <assgn> <copy><from varable="v1n3" part="accept"/><to varable="v2" part="accept"/></copy> <target lnkname="data-assgn-to-reply"/> <source lnkname="n3data-to-reply"/> </assgn> <reply name="manreply" partnerlnk="customer" porttype="apns:op1" operaton="approve" varable="v2" joncondton="(bpws:getlnkstatus( setmessage-to-reply ) or bpws:getlnkstatus( op2-toreply )) and (bpws:getlnkstatus( n3data-to-reply ) or not(bpws:getlnkstatus( n3data-to-reply ))) and (bpws:getlnkstatus( n2data-toreply ) or not(bpws:getlnkstatus( n2data-to-reply )))"> <target lnkname="setmessage-to-reply"/><target lnkname="op1"/> <target lnkname="n3data-to-reply"/> <target lnkname="n2data-to-reply"/> </reply> 7.4 Synthèse Pour valder nos travaux, nous nous sommes attachés à les concrétser par un produt logcel. Cette approche pragmatque, reposant sur une réalsaton d outls, consttue, à notre sens, un moyen prncpal d évaluer objectvement l apport de notre contrbuton. Les travaux décrts dans ce document ont about à la réalsaton de deux outls complémentares : SDS/PPP (Servce wth Decentralzed Support/ Peer Process Producer). Dans ce chaptre, nous avons présenté les réalsatons logcelles que nous avons développées pour tester la fasablté de nos travaux. La réalsaton consdère un envronnement dstrbué hétérogène. Les dffcultés ont été nombreuses non seulement pour structurer un très gros logcel (dont le développement attent mantenant pluseurs mllers de lgnes de code), mas auss pour ntégrer toutes les contrantes assocées aux envronnements dstrbués hétérogènes. La premère mplémentaton concerne la réalsaton de la moblté des spécfcatons de procédés entre les servces. Cette parte de l mplémentaton est basée sur l extenson de l mplémentaton d un système de geston de workflow. L envronnement du système de geston de workflow gère les problèmes de communcaton, concurrence et tolérance aux pannes entre les exécutons des procédés coopérants. La réalsaton des servces nvoqués avec les procédés coopérants (SDS) n état pas une tâche fastdeuse car nous avons conçu une nterface de servce qu mplémente les opératons d admnstraton du moteur de workflow. Cette réalsaton permet de réalser l exécuton décentralsée de manère effcace par la moblté des procédés coopérants. Intutvement, cette mplémentaton qu consdère les hypothèses archtecturales, est plus smple à réalser par rapport à ceux qu ont été proposées dans la lttérature scentfque. Cette faclté de réalsaton état un des objectfs de notre traval. La deuxème mplémentaton (PPP) qu produt les procédés coopérants échangés porte sur la réalsaton des algorthmes présentés dans les chaptres précédents. Nous avons utlsé WS-BPEL comme le langage de procédé. Ce chox est en parte ntutf comme la dernère est le standard 155

172 Chaptre 7. Mse en œuvre consdéré par l ndustre. Notre approche état sur des hypothèses smplfcatrces comme la décentralsaton des procédés structurés. Ces hypothèses smplfcatrces restent valables pour les procédés WS-BPEL tratés. Contrarement à l mplémentaton du module SDS, la réalsaton du PPP a été généralement une tâche fastdeuse, nous sommes en tran de développer une nterface utlsateur proposant une forme graphque homogène pour la sase des données du flux d nformaton, la geston des menus ans que pour la vsualsaton des résultats. Cette normalsaton permettra de réalser, de manères effcace, des nterfaces partcularsables par le concepteur de procédé. Le concepteur du procédé n aura alors plus à se préoccuper de la manpulaton des données graphques. L mplémentaton actuelle est une applcaton Java qu utlse prncpalement les APIs pour la manpulaton des fchers XML. Le module PPP peut être décomposé en couches qu s emplent depus le nveau le plus physque (celu des messages reçus) jusqu au nveau le plus applcatf dans lequel on trouve les algorthmes mplémentés et l nterface de concepteur. Pour ces dernères, l mplémentaton apparaît ben sûr comme une seule entté, masquant la complexté de la réalsaton avec des classes varées. Le but ultme de PPP est tester la fasablté des algorthmes qu produsent les procédés coopérants. Nous avons constaté que WS-BPEL a des éléments que nous n avons pas consdérés dans le développement de notre approche tels que la geston des exceptons et l expresson de la structure par des éléments dfférents. Il est à noter que notre traval ne portat pas sur un langage spécfque, mas le plus générque possble. 156

173 Chaptre 8 Conclusons et perspectves Sommare 8.1 Rappel du contexte et des objectfs de la thèse Blan des contrbutons Perspectves Rappel du contexte et des objectfs de la thèse Le paradgme Archtectures Orentée Servces (AOS) décrt l utlsaton de servces pour supporter le développement d applcatons dstrbuées, nter-opérables, et agles. Les servces sont vus comme des enttés autonomes et sont ndépants de la plate-forme sur laquelle ls s exécutent. La vson assocée à AOS consste à assembler dfférents servces afn d obtenr un ensemble de servces fablement couplés qu supportent de manère agle des procédés méters composés de pluseurs entreprses et s exécutant sur dfférentes plate-formes/outls. Cette vson va au-delà du smple échange d nformaton qu est actuellement le moyen prvlégé pour que pluseurs entreprses coopèrent. Les standards de servces Web sont actuellement la technologe et les ntergcels les plus prometteurs pour mettre en œuvre cette vson. Cela permet aux entreprses d exposer leurs compétences à travers des servces qu sont dsponbles quelques sot la plate-forme (pc, téléphone, pda,...) et d utlser éventuellement les servces exposés par les autres entreprses. En rason de la nature nter-organsatonnelle des procédés méters basés sur la composton des servces mantenus par les dfférents partenares, la gouvernance de leurs nteractons mutuelles est un déft mportant. En effet, une composton de servces utlsée dans un procédé méter nter-organsatonnel ne pourra fonctonner correctement et effcacement que s les nteractons des servces sont gouvernées en accord avec d une part les objectfs, et d autre part avec les poltques défnes par chaque partenare et par le contexte. Ans, les servces dovent respecter les objectfs fonctonnels, mas également les objectfs non-fonctonnels tels que les contrantes du flux d nformaton et le chox dynamque des servces. Actuellement, les dvers travaux sur la composton se sont bornés à étuder les aspects fonctonnels d une composton par une approche centralsée telle que l orchestraton ou par une approche chorégraphe plus décentralsée. Cela n est plus suffsant, avec la prse en compte de crtères non-fonctonnels, en partculer pour amélorer la gouvernance des nteractons des servces composant un procédé d une manère systématque. Un modèle d exécuton décentralsée dans lequel les servces composés peuvent avor des nteractons restrentes par les contrantes de chaque composton est un beson prmordal 157

174 Chaptre 8. Conclusons et perspectves pour profter des avantages respectfs des modaltés d exécuton centralsées et décentralsées. Le modèle dot également permettre la spécfcaton et le tratement des contrantes qu spécfent les nteractons. Une autre caractérstque nécessare à la re-modélsaton de l exécuton des procédés méters nter-organsatonnels est la conformté de l approche proposée aux efforts de standardsaton. Conceptuellement, un modèle alternatf est nécessarement dfférent des modèles habtuels par les hypothèses archtecturales qu l engre. Le problème est d autant plus complexe s on exge que ces hypothèses soent plus rasonnables par rapport aux mplémentatons actuelles. Dans ce contexte, le but de notre traval état de proposer une nouvelle approche de modélsaton et d exécuton des procédés méters orentés servces. La premère caractérstque exgée d une telle approche est sa conformté aux efforts de standardsaton. Concernant la vson conceptuelle, la nouvelle approche dot trater les dffcultés respectves des approches prncpales afn de proposer une exécuton qu explote leurs avantages complémentares. Dans cette nouvelle nfrastructure d exécuton, les nteractons des servces composés dovent être en adéquaton avec pluseurs types de restrctons mposées à la composton. Notre domane de recherche est assez large pusqu l couvre un ensemble de problèmes lés à la modélsaton, l analyse des procédés méters et à la réalsaton de systèmes dstrbués. Pour chacun de ces problèmes, l a été nécessare de maîtrser et de développer les théores et les technques assocées. 8.2 Blan des contrbutons Le traval que nous avons présenté décrt une méthodologe et une archtecture pour fournr un envronnement d exécuton décentralsée dans lequel les servces composés peuvent établr des nteractons d égal-à-égal. Comme nous l avons soulgné c-dessus, l mplémentaton des nteractons est gouvernée par pluseurs type de restrctons mplquées à la composton. Nous avons défn une méthodologe de génératon de procédés coopérants à partr d une spécfcaton centralsée de la composton. Ces procédés coopérants déployés vers les servces composés permettent les nteractons d égal-à-égal des servces. L mplémentaton des nteractons est gouvernée par les restrctons défnes à la fos par les concepteurs de composton et à la fos par les éléments contextuels. Dans un premer temps, le déploement est effectué selon une approche statque et dans un deuxème temps les aspects lés au déploement dynamque des procédés sont étudés. Ans, nos recherches ont ntégrés dfférents aspects : Méthodologques : nous avons défn et synthétsé les étapes de l approche globale permettant de passer de la modélsaton d une composton à la réalsaton de son exécuton décentralsée. L approche est motvée par les avancements des efforts de standardsaton qu permettent l échange de la spécfcaton des procédés entre dfférents organsatons et outls, Formels : nous avons ntégré l approche workflow pour la modélsaton et développé une nterprétaton partculère du modèle, sur la base du calcul d un ensemble de crtères prncpaux tels que les aspects conversatonnels, les flots de contrôle et de données. Nos consdératons ncluent une spécfcaton pour l expresson de restrctons pour l mplémentaton des nteractons d égal-à-égal. L utlsaton de paradgmes workflow facltent la compréhenson et la vérfcaton des concepts de l approche. Technques : la maîtrse des caractérstques et des contrantes du langage WS-BPEL a été nécessare pour réalser le prototype qu valde notre approche. La méthodologe proposée a pour qualté d être smple et complète, d un pouvor d expresson équvalent à celu des spécfcatons standardsée telles que WS-BPEL. Les concepts utlsés 158

175 8.3. Perspectves sont plus nombreux et meux formalsés que les méthodologes smlares de la lttérature. Nous résumons les contrbutons prncpales de cette thèse comme c-dessous : Nous avons ntrodut une technque pour décentralser un procédé nter-organsatonnel centralsé en respectant sa sémantque et en allant vers des nteractons d égal-à-égal entre les servces composés par celu-c. Cette contrbuton consste en la défnton de structures de données et d algorthmes qu respectvement caractérsent et tratent les procédés méters en vue de fournr les procédés coopérants que les servces composés dovent mettre en œuvre. Nous avons ntrodut un langage de base pour exprmer les restrctons mposées aux nteractons d égal-à-égal des servces composés. Nous avons présenté également les algorthmes qu tratent ce langage en vue de spécfer les nteractons des servces. Les technques développées dans l étape précédente sont adaptées à cette deuxème contrbuton en permettant la confguraton des nteractons des procédés coopérants fourns. La dernère contrbuton se penche sur la sélecton dynamque et décentralsée de servces lors de l exécuton avec les procédés coopérants. Nous avons proposé une technque qu ntègre les problèmes de synchronsaton développés précédemment. Les contrbutons conceptuelles c-dessus sont valdées par les outls logcels développés. La premère valdaton logcelle porte sur la proposton d un outl de tratement et de décentralsaton de WS-BPEL. Nous avons également développé une archtecture de référence pour les servces qu peuvent supporter la moblté des spécfcaton de procédés. 8.3 Perspectves Au delà des restrctons du flux d nformaton présentées, l approche que nous avons menée autour de la moblté des procédés dérvés à partr d une spécfcaton centralsée consttue une méthodologe nouvelle qu est, à nos yeux, extensble à dverses restrctons. La mse en œuvre a perms de dégager pluseurs ponts qu restent à approfondr. La verson du prototype permettant de produre des procédés coopérants d une spécfcaton est quasment opératonnelle. A partr de cette verson, nous envsageons d entamer une campagne d mplémentaton des restrctons afn d enrchr les poltques mplémentées. Parallèlement, pluseurs modfcatons, tant d un pont de vue optmsaton qu extenson, seront effectuées. Elles concerneront en partculer les ponts suvants : L actuelle décentralsaton d une spécfcaton centralsée en procédés coopérants repose sur des hypothèses encore restrctves. La caractérsaton formelle de certanes proprétés des procédés telles que les spécfcatons structurées, permettra d étre la classe des spécfcatons centralsées décentralsables. Pour cela, l faudra également ntégrer de manère formelle ces nouvelles fonctonnaltés au prototype développé, Dans la perspectve de produre des procédés coopérants, nous envsageons d étre les restrctons actuelles. Les problèmes lés au contrôle de flux d nformaton dans une composton de servces nécesstent la compréhenson et l ntégraton d aspects qu sont souvent étudés séparément comme le contrôle d accès, la geston de la confance ou la vérfcaton d une descrpton de chorégraphe. Dans ce contexte, le tratement des poltques nécesste un modèle plus global. La méthodologe n ntégrant les spécfctés du langage cble que dans les étapes ultmes, nous envsageons de l applquer à la génératon d autres langages cbles (BPMN, WS-CDL,...). Concernant l mplémentaton du chox dynamque de servces, un placement avancé des 159

176 Chaptre 8. Conclusons et perspectves canaux de communcaton sur les dfférents stes de l nfrastructure de communcaton est également envsagé. Cec est également lé au chox d mplémentaton du chox dynamque. Afn d éprouver les lmtes de notre système de décentralsaton, en partculer lés aux composants externes et à l expresson des restrctons et des spécfcatons centralsées, nous envsageons de trater une applcaton réelle. C-dessus nous avons résumé les perspectves mmédates de notre traval. Nous pouvons étre ces perspectves dans des pstes dfférentes. Les perspectves à long terme de notre traval s artculent sur tros pont prncpaux : L expérmentaton de notre prototype nous a condut à observer certanes lmtes lées à l utlsaton des spécfcatons orentées graphes. Par exemple, s celles-c sont parfatement adaptés à la spécfcaton/vérfcaton de comportements, elles sont mons approprés à la descrpton de comportements conversatonnels. D autres formalsmes comme les spécfcatons algébrques, devraent, sur ce pont, apporter des solutons satsfasantes. De même, d autres méthodes formelles (e.g. théore des automates) permettraent d étuder de nouveaux aspects de la dynamque des nteractons entre les servces. L explotaton des proprétés ssues du contrôle du flux d nformaton est un problème qu ouvre un champ de perspectves mportant. Lorsqu une restrcton ntéressante par rapport à la sécurté est mplémentée, l est souvent dffcle de transférer une donnée sur un chemn dynamquement défn. Ce pont devent partculèrement délcat lorsque les technques utlsées sont encapsulées par des formalsmes de haut nveau tratées avant l exécuton où la réponse obtenue est encore du type ou/non. Étuder les mécansmes permettant de tradure ces restrctons, dans les termes du formalsme de haut nveau, en exécuton décentralsée est une perspectve nécessare à la popularsaton de l approche globale de l exécuton décentralsée. L mplémentaton des poltques ssues du contrôle du flux d nformaton est pertnente pour exploter l archtecture d un système décentralsé et proposer des drectves de placement afn d en optmser leur exécuton. Ce pont est en cours d étude. Nous envsageons dans un premer temps de défnr un len entre les restrctons utlsées actuellement et les crtères lés à la talle des données échangées. À terme, l sera peut-être possble de proposer des modèles plus proches de ceux des workflows scentfques qu sont orentés données. Un autre problème des méthodes de concepton/développement est la prse en compte de l exstant. L approche pour l mplémentaton de la composton par des procédés coopérants offre une soluton à leur prse en compte dans un nouveau mode d exécuton. Cepant, pour s assurer de la conformté d un composant logcel à son abstracton, un retour aux technques tradtonnelles de tests est nécessare. L explotaton de cette abstracton pour générer automatquement des séquences de tests de conformté et de robustesse est une perspectve ntéressante. Des travaux sur ce sujet ont été entamés. Ce pont s ntéresse à l utlsaton des standards comme WS-Transactons, WS-Securty et WS-RelableMessagng. 160

177 Annexe A Le tratement des procédés WS-BPEL Extracton des dépances à partr d une spécfcaton WS-BPEL Dans cette secton, nous donnons le lstng du module de l mplémentaton qu analyse les procédés WS-BPEL. Le but des analyses fates par cette classe est d dentfer les types de dépances nécessares à la producton des procédés coopérants comme nous l avons llustré dans le chaptre 4. /** * * YILDIZ Ustun /5/3 */ mport java.o.fle; mport java.o.flenotfoundexcepton; mport java.o.ioexcepton; mport javax.swng.joptonpane; mport java.utl.iterator; mport java.utl.lst; mport java.utl.lnkedlst; mport org.jdom.element; mport org.jdom.jdomexcepton; mport org.jdom.nput.saxbulder; mport org.jdom.xpath.xpath; publc class ParcoursXPATH { /* * Creer une nouvelle nstance de ParcoursXPATH */ publc ParcoursXPATH() { } /* * recupere un document WS-BPEL a partr du fcher _FlePath, * appelle la methode chose par l utlsateur */ publc vod parcours(fle _FlePath) { Strng elem ; org.jdom.document document = null ; 161

178 Annexe A. Le tratement des procédés WS-BPEL try { /* On crée une nstance de SAXBulder */ SAXBulder sxb = new SAXBulder(); document = sxb.buld(_flepath); } catch (IOExcepton e) { System.out.prntln("Erreur lors de la lecture du fcher " + e.getmessage() ); e.prntstacktrace(); } catch (JDOMExcepton e){ System.out.prntln("Erreur lors de la constructon du fcher JDOM " + e.getmessage() ); e.prntstacktrace(); } try { /* On ntalse un nouvel élément avec l élément racne du document. */ Element debrech = document.getrootelement() ; Object[] choxpossbles = {"Predecesseurs", "Successeurs", "Predecesseurs & Successeurs", "Successeurs jusqu a conjoncton", "Predecesseurs jusqu a dsjoncton", "Elements n etant pas sur le meme chemn", "Chemn passant par N ponts", } ; /* c on ntalse les varables de base de l analyse*/ Object chox = JOptonPane.showInputDalog(null, "Chosssez une des optons suvantes:", "Operatons a effectuer", JOptonPane.QUESTION_MESSAGE, null, choxpossbles, choxpossbles[2] ) ; Iterator<Element> ter = null ; LnkedLst<Element> lste = null ; StrngBuffer st = null ; f (chox.equals("predecesseurs") chox.equals("predecesseurs & Successeurs")) { elem = JOptonPane.showInputDalog(null, "Quel element souhatez-vous chercher?", "Ttre", JOptonPane.QUESTION_MESSAGE) ; lste = lstpred(document.getrootelement(), elem) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des predecesseurs de "+elem+" : ") ; whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE ) ; } f (chox.equals("successeurs") chox.equals("predecesseurs & Successeurs")) { elem = JOptonPane.showInputDalog(null, "Quel element souhatez-vous chercher?", "Ttre", JOptonPane.QUESTION_MESSAGE) ; lste = lstsucc(document.getrootelement(), elem) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des successeurs de "+elem+" : ") ; whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } 162

179 JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE ) ; } f (chox.equals("successeurs jusqu a conjoncton")) { elem = JOptonPane.showInputDalog(null, "Quel element souhatez-vous chercher?", "Ttre", JOptonPane.QUESTION_MESSAGE) ; lste = succapontconj(document.getrootelement(), elem) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des successeurs de "+elem+" jusqu a conjoncton: ") ; } whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE ) ; f (chox.equals("predecesseurs jusqu a dsjoncton")) { elem = JOptonPane.showInputDalog(null, "Quel element souhatez-vous chercher?", "Ttre", JOptonPane.QUESTION_MESSAGE) ; lste = predapontdsj(document.getrootelement(), elem) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des predecesseurs de "+elem+" jusqu a dsjoncton: ") ; whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE) ; } f (chox.equals("elements n etant pas sur le meme chemn")) { elem = JOptonPane.showInputDalog(null, "Quel element souhatez-vous chercher?", "Ttre", JOptonPane.QUESTION_MESSAGE) ; lste = pasmemechemn(document.getrootelement(), elem) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des elements n etant pas sur le meme chemn que "+elem+" : ") ; whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE ) ; } f (chox.equals("chemn passant par N ponts")) { Strng s = JOptonPane.showInputDalog("Comben de ponts de passage souhatez-vous defnr?") ; nt nbponts = Integer.decode(s).ntValue() ; Strng[] ponts = new Strng[nbPonts] ; for (nt =0 ; <nbponts ; ++) { ponts[] = JOptonPane.showInputDalog("Pont numero "+(+1)) ; } 163

180 Annexe A. Le tratement des procédés WS-BPEL lste = passn(document.getrootelement(), ponts) ; ter = lste.lstiterator() ; st = new StrngBuffer("Lste des elements fgurants sur ce chemn : ") ; whle (ter.hasnext()){ st.app((ter.next()).gettexttrm()+" ") ; } JOptonPane.showMessageDalog(null, st.tostrng(), "Resultat", JOptonPane.PLAIN_MESSAGE ) ; } } catch (Excepton e) { System.out.prntln("Erreur dans parcours(fle) : " + e.getmessage() ); e.prntstacktrace(); } }// fn de parcours(fle _FlePath) /* * recherche d un element elem en partant de debrech */ publc Element rechercheelement(element debrech, Strng elem) { Element res = null ; try { f (debrech.gettexttrm().equals(elem)) return debrech ; /* On recherche elem chez les enfants de debrech. */ Lst<Element> l = debrech.getchldren() ; Iterator<Element> t = l.terator() ; Element nc = null ; whle(t.hasnext()) { nc = t.next() ; nc = rechercheelement(nc,elem) ; res = (res==null?nc:res) ; } } catch (Excepton e) { System.out.prntln("Erreur dans rechercheelement(element,strng) : " + e.getmessage() ) ; e.prntstacktrace() ; } return res ; }// fn de rechercheelement(element,strng) /* * etablt la lste des predecesseurs de elem en partant de racne */ publc LnkedLst lstpred(element racne, Strng elem) { try { f (racne.gettexttrm().equals(elem)){ /* s la racne est l element recherche */ LnkedLst lste = new LnkedLst() ; return lste ; } else { f (racne.getchldren().sze()!=0) { f (!racne.gettexttrm().equals("")) { LnkedLst lste = lstpred(racne.getchld("and"),elem) ; lste.addfrst(racne) ; return lste ; } else { /* l y a des or */ Lst<Element> l = racne.getchldren() ; 164

181 LnkedLst<Element> lste = new LnkedLst() ; /* Parcours de chaque or a fond jusqu a trouver elem */ boolean trouve = false ; nt ; nt j = -1 ; for(=0 ; <l.sze() &&!trouve ; ++) { f ((l.get()).getname().equals("lnk")) { trouve = content(l.get(),elem) ; } else { j = ; } } f (!trouve){ /* elem n a pas ete trouve. * on ajoute tous les elements dans la lste */ for(=0 ; <l.sze() ; ++) { f ((l.get()).getname().equals("or")) { ajoutelste(l.get(),lste) ; } else { j = ; } } /* pus on contnue le parcours. */ lste.addall(lstpred(l.get((j==-1?-1:j)),elem)) ; } else { /* elem a ete trouve. * on ajoute seulement les elements de la branche specfee */ lste.addall(lstpred(l.get((j==-1?-1:j)),elem)) ; } return lste ; } } } } catch (Excepton e) { System.out.prntln("Erreur dans lstpred(element,strng) : " + e.getmessage() ) ; e.prntstacktrace() ; } return new LnkedLst() ; }// fn de lstpred(element,strng) /* * etablt la lste des predecesseurs de elem en partant de racne */ publc LnkedLst lstsucc(element racne, Strng elem){ try { f (racne.gettexttrm().equals(elem)){ /* s la racne est l element recherche */ /* on renvoe tous les successeurs */ LnkedLst lste = new LnkedLst() ; ajoutelste(racne,lste) ; lste.remove(racne) ; return lste ; } else { f (racne.getchldren().sze()!=0) { f (!racne.gettexttrm().equals("")) { return lstsucc(racne.getchld("flow"),elem) ; } else { Lst<Element> l = racne.getchldren() ; LnkedLst<Element> lste = new LnkedLst<Element>() ; /* Parcours de chaque or a fond jusqu a trouver elem */ boolean trouve = false ; 165

182 Annexe A. Le tratement des procédés WS-BPEL nt ; nt j = -1 ; for(=0 ; <l.sze() &&!trouve ; ++) { f ((l.get()).getname().equals("or")) { trouve = trouve content(l.get(),elem) ; } else { j = ; } } f (!trouve){ /* elem n a pas ete trouve. * on contnue sur le flow */ lste = lstsucc(l.get((j==-1?-1:j)),elem) ; } else { /* elem a ete trouve. * on ajoute les successeurs de elem */ lste = lstsucc(l.get((j==-1?-1:j)),elem) ; /* on ajoute les successeurs du flow */ f ((l.get(l.sze()-1)).getname().equals("flow")) ajoutelste(l.get(l.sze()-1),lste) ; } return lste ; } } } } catch (Excepton e) { System.out.prntln("Erreur dans lstsucc(element,strng) : " + e.getmessage() ) ; e.prntstacktrace() ; } return new LnkedLst() ; }// fn de lstpred(element,strng) /* * toutes les actvtes entre 2 précses */ publc LnkedLst actentre2(element racne,strng e1,strng e2) { LnkedLst<Element> l1 = lstsucc(racne,e1); LnkedLst<Element> l2 = lstpred(racne,e2); LnkedLst<Element> res = new LnkedLst<Element> (); Element tmp1; Element tmp2; boolean trouve; for (nt =0 ; <l1.sze() ; ++) { tmp1 = l1.get(); trouve = false; for (nt j=0 ; j<l2.sze() &!trouve ; j++) { tmp2 = l2.get(j); f(tmp1.equals(tmp2)) { trouve = true; res.add(tmp1); } } } return res; }//fn actentre2 /* * Predecesseur d un element a un autre */ publc LnkedLst predentre2(element racne,strng e1,strng e2) { return actentre2(racne,e2,e1); }//fn predentre2 166

183 /* * successeur d un element a un autre */ publc LnkedLst succentre2(element racne,strng e1,strng e2) { return actentre2(racne,e1,e2); }//fn succentre2 /* * successeur jusqu au pont de conjoncton */ publc LnkedLst succapontconj(element racne, Strng elem) { Strng conj; Element elt = rechercheelement(racne,elem); Element parent = elt.getparentelement(); Lst<Element> l = parent.getchldren(); Element tmp = null; boolean trouve = false; whle(!trouve) { for (nt =0 ; <l.sze() &!trouve ; ++) { tmp = l.get(); f(((tmp.getname()).equals("flow")) && (!((tmp.gettexttrm()).equals(elem))) && (!((tmp.gettexttrm()).equals("") trouve = true; } } parent = parent.getparentelement(); l = parent.getchldren(); } conj = tmp.gettexttrm(); return succentre2(racne, elem, conj); }//fn succapontconj /* * predecesseur jusqu au pont de dsjoncton */ publc LnkedLst predapontdsj(element racne, Strng elem) { Strng dsj; Element elt = rechercheelement(racne,elem); Element parent = elt.getparentelement(); boolean trouve = false; whle(!trouve) { f( ((parent.getname()).equals("flow")) && ((parent.gettexttrm()).equals("")) ) { trouve = true; } parent = parent.getparentelement(); } dsj = parent.gettexttrm(); return predentre2(racne, elem, dsj); }//fn predapontdsj /* * Etablt la lste des elements qu ne sont pas sur le meme chemn que elem */ publc LnkedLst pasmemechemn(element racne, Strng elem) { // lste de tous les elements du graphe LnkedLst<Element> touselem = lstsucc(racne, racne.gettexttrm()) ; touselem.addfrst(racne) ; // lste des predecesseurs de elem LnkedLst<Element> chemn = lstpred(racne, elem) ; // lste des successeurs de elem LnkedLst<Element> succ = lstsucc(racne, elem) ; // concatenaton des predecesseurs de elem avec les successeurs de elem chemn.add(rechercheelement(racne,elem)) ; chemn.addall(succ) ; // recherche des elements qu ne sont pas sur le meme chemn que elem LnkedLst<Element> paschemn = new LnkedLst<Element>() ; boolean trouve ; 167

184 Annexe A. Le tratement des procédés WS-BPEL for (nt =0 ; <touselem.sze() ; ++) { trouve = false ; for (nt j=0 ; j<chemn.sze() &&!trouve ; j++){ trouve = touselem.get().equals(chemn.get(j)) ; } f (!trouve) paschemn.add(touselem.get()) ; } return paschemn ; } /* * Etablt la lste des elements */ LnkedLst passn(element racne, Strng[] ponts) { // Recherche des predecesseurs et successeurs passant par le premer pont LnkedLst<Element> res = lstpred(racne,ponts[0]) ; res.add(rechercheelement(racne,ponts[0])) ; res.addall(lstsucc(racne,ponts[0])) ; // Creaton d un clone pour les comparasons LnkedLst<Element> comp = new LnkedLst(res) ; // On retre mantenant les elements qu ne sont pas dans la lste des // predecesseurs/successeurs des ponts suvants for (nt =1 ; <ponts.length ; ++) { LnkedLst<Element> tmp = lstpred(racne,ponts[]) ; tmp.add(rechercheelement(racne,ponts[])) ; tmp.addall(lstsucc(racne,ponts[])) ; for (nt j=0 ; j<comp.sze() ; j++) { boolean trouve = false ; for (nt k=0 ; k<tmp.sze() &&!trouve ; k++) { trouve = comp.get(j).equals(tmp.get(k)) ; } f (!trouve) res.remove(comp.get(j)) ; } } return res ; } /* * test s l element elem et un successeur de elt */ publc boolean content(element elt, Strng elem) { boolean test = elt.gettexttrm().equals(elem) ; Lst<Element> l = elt.getchldren() ; Iterator<Element> ter = l.terator() ; whle(ter.hasnext()){ Element e = ter.next() ; test = test content(e,elem) ; } return test ; }// fn de content(element,strng) /* * ajoute a la lste lste tous les successeurs de elt */ publc vod ajoutelste(element elt, LnkedLst lste) { f (!elt.gettexttrm().equals("")) lste.add(elt) ; Lst<Element> l = elt.getchldren() ; Iterator<Element> ter = l.terator() ; whle(ter.hasnext()){ Element e = ter.next() ; ajoutelste(e,lste) ; } }// fn ajoutelste(element,lnkedlst) }// fn class ParcoursXPATH 168

185 169

186 Annexe A. Le tratement des procédés WS-BPEL 170

187 Annexe B La recherche de chemn par le tratement des poltques du flux d nformaton La recherche de chemn en vue d dentfer les chemns fables qu remplacent d nteractons Dans cette secton, nous donnons les détalles de l algorthme que nous avons mplémenté pour trouver les chemn fables qu remplacent les nteractons qu ne sont pas en adéquaton avec les poltques du flux d nformaton. Ce mécansme est explqué dans le chaptre 5. C-dessous nous présentons les classes prncpales que nous avons mplémentées. Classe Graphe package tm; publc class Graph { publc statc fnal strng can\_route(); publc statc fnal strng can\_route\_to(); publc statc fnal strng can\_route\_from(); publc statc fnal strng can\_route\_to(); nt vv=0; nt v=8;// nombre des noeuds nt e=10;// nombre des arcs. Noeud[] V=new Noeud[v]; Arret[] E=new Arret[e]; Noeud[] AA=new Noeud[v]; publc vod sasr(){ Claver c=new Claver(); System.out.prnt("Les poltques: "+"\n"); for(nt =0;<ths.v;++){ Strng s=c.lrestrng(); Noeud no=new Noeud(); no.n=s; V[]=no; } for(nt =0;<ths.e;++){ Strng s; Arret ar=new Arret(); 171

188 Annexe B. La recherche de chemn par le tratement des poltques du flux d nformaton s=c.lrestrng(); ar.depar.n=s; //E[]=ar; s=c.lrestrng(); ar.arrve.n=s; //E[]=ar1; s=c.lrestrng(); Strng montexte = new Strng(s); Integer monnombre=new Integer(montexte); nt p = monnombre.ntvalue(); ar.w=p; E[]=ar; } } publc nt calcul_adequaton(noeud nn){ //Noeud nn=new Noeud(); nt d=0; nt k=0; vv=0; whle(k<ths.e){ //f( E[k].depar.n==nn.n E[k].arrve.n==nn.n){ f(nn.n.equals(e[k].depar.n)){ nn.ww[vv]=e[k].w; nn.vos1[vv]=e[k].arrve;vv++;} f(nn.n.equals(e[k].arrve.n)){ nn.ww[vv]=e[k].w; nn.vos1[vv]=e[k].depar;vv++; } k++;} for(nt u=0;u<ths.v;u++){ f(nn.n.equals(ths.v[u])) d=u; } ths.v[d].vos1=nn.vos1; //} nn.v=vv; return vv; } Noeud calcule_mn_d(){ nt m=aa[0].d; Noeud n=new Noeud(); for(nt =0;<ths.v;++){ f(aa[].d<=m && AA[].n.equals("-1")==false){ m=aa[].d; n=aa[];} } return n; } publc vod trater(){ Noeud nu=new Noeud(); V[0].d=0;V[0].p=V[0]; for(nt =1;<ths.v;++){ V[].d=1000; V[].p=null; V[].p.n="null"; } AA=V; 172

189 nt u=0; nt dd=0; whle(u<ths.v){ for(nt =u;<ths.v;++) for(nt j=;j<ths.v;j++){ f(aa[].d>aa[j].d ){ Noeud t=aa[]; AA[]=AA[j]; AA[j]=t; } } nu=aa[u]; //nu=calcule_mn_d(u); calcul_vosn( nu); for(nt =0;<nu.v;++){ f(nu.vos1[].d>nu.d+nu.ww[]){ nu.vos1[].d=nu.d+nu.ww[]; dd=dd+nu.vos1[].d; nu.vos1[].p=nu; //nu.vos1[].p.n=nu.n; //System.out.prnt(nu.n+"----->"+nu.Vos1[].n+" "+nu.vos1[].d+"\n"); //System.out.prnt(AA[u].n+"\n"); for(nt k=0;k<v;k++){f(nu.vos1[].n.equals(aa[k].n)) AA[k]=nu.Vos1[]; } } } for(nt =0;<ths.v;++){ System.out.prnt("("+AA[].d+","+AA[].p.n+")"+"\n"); } System.out.prnt(" "+"\n"); //System.out.prnt(nu.n+"---"); //AA[u].n="-1"; u++; } System.out.prnt(Le chemn est: AA"\n"); } publc Graph(nt v,nt e){ ths.vv=0; ths.v=v; ths.e=e; Noeud[] V1=new Noeud[v]; Arret[] E1=new Arret[e]; Noeud[] AA1=new Noeud[v]; ths.aa=aa1; ths.v=v1; ths.e=e1; } } publc class Arret { Noeud depar; Noeud arrve; nt w; publc Arret(){ Noeud depar=new Noeud(); 173

190 Annexe B. La recherche de chemn par le tratement des poltques du flux d nformaton ths.depar=depar; Noeud arrve=new Noeud(); ths.arrve=arrve; } } Classe Nud package tm; publc class Noeud { Strng n; nt v; nt d; Noeud p; Noeud[] Vos1=new Noeud[71]; nt[] WW=new nt[71]; publc Noeud(){ ths.d=1000; Noeud[] Vos1=new Noeud[71]; nt[] WW=new nt[71]; ths.ww=ww; ths.vos1=vos1; } } 174

191 Annexe C La preuve du théorème de l exacttude Dans cette annexe, nous détallons la preuve du théorème que nous avons utlsé dans le chaptre 5. Le but de ce théorème est de prouver la relaton d équvalence entre la spécfcaton centralsée d un procédé de composton et ses procédés coopérants dérvés. Il est à noter que ce théorème valde les algorthmes de transformaton au leux de procéder une vérfcaton sur les procédés coopérants dérvés. Pour ce fare, nous utlsons des défntons qu complément celles qu sont décrtes dans les chaptres 4 et 5. Défnton 1 Une transton est un tuple (A s, A c, lbl) (2 A, A, Conds) où A s est un ensemble d actvtés sources, A c est un ensemble d actvtés cbles et lbl est les états de condtons de transtons. Nous pouvons défnr la sémantque du procédé comme une automate à états fns en dentfant (a) un ensemble d états, (b) un ensemble de relatons de transton, (c) un ensemble d états ntaux, celu-c est un sngleton, (d) un ensemble d états fnaux, celu-c est un sngleton. Par rapport au théorème que nous essayons de prouver, l ensemble (a) est le contexte que nous allons défnr dans la défnton 2 c-dessous. L ensemble (b) est la foncton step que nous allons défnr dans la défnton c-dessus. Les ensembles (c) et (d) sont défns avec ces défntons. Défnton 2 Sot P une spécfcaton de procédé centralsée, un contexte partculer cp de procédé, > 1, une transton t = (source, cble, E[C]A), t T est l ensemble de toutes les transtons de procédé, actvée à l nstant s et seulement s les condtons suvantes sont vraes : s cp CP eval(e, cp, cp +1 ) = générée, s source = et t T au même étape de transton qu précède un pont OR-splt, s source = et t T au même étape de transton qu précède un pont AND-splt. Une transton peut être évaluée s pluseurs crtères sont vraes en même temps. Les deux crtères prncpaux qu nous ntéressent est l actvté source de la dépance de contrôle est dans un état qu permet l exécuton de l actvté suvante par rapport au flux de contrôle et les données sur lesquelles les condtons de transtons sont exprmées sont ntalsées. Après l évaluaton d une transton, une nouvelle étape de l exécuton nommée cp +1 est valable. Un contexte partculer ntal est défn comme cp 0 pour les contextes partculers non-ntalsés. Un contexte partculer peut changer s au mons une transton devent vrae. La foncton eval() est 175

192 Annexe C. La preuve du théorème de l exacttude utlsée pour évaluer les condtons exprmées des transtons. Plus formellement, on peut noter une transton comme sut. A partr d un contexte partculer cp 1, et un ensemble de transton T, > 0, le contexte cp est défn par l nducton suvante : s s cp 1 t T 1 source(t) alors s est dans cp ; s t T 1 s target(t) alors s cp où source(t) et target(t) sont les ensembles des états quttés et entrées, respectvement, des transtons qu sont évaluées. Intutvement, un état est un élément d un nouveau contexte. Quand une transton est évaluée, le composant acton d ECA est exécuté ce qu fat que les autres éléments du contexte tels que les événements, condtons et les varables sont changés. Plus formellement, on peut défnr le changement du contexte peut être défn comme dans la défnton 3. Défnton 3 Sot un ensemble de condtons, C, d événements E et de données D, un contexte à l nstant est défn comme sut. cp : C E D {vra, faux}, cp est défn : eval(x), s eval(x),, eval(x) =, cp 1 (x), pour les autres cas. Le contexte peut changer s l y a des évaluatons explctes à cause des external stmul. Homomorphsme des spécfcatons Dans cette secton, nous présentons les éléments prncpaux qu nous ont perms de vérfer la préservaton de la sémantque centralsée des procédés décentralsés. L équvalence de la sémantque de deux systèmes est décrt par le même comportement externe qu on peut observer sous le même external stmul. Cela veut dre que les procédés décentralsés exécutent les actvtés respectves dans le même ordre que la spécfcaton centralsée. Comme nous l avons mentonné déjà, en consdérant le procédé comme une structure algébrque avec son contexte pour son ensemble, et les opératons d évaluaton comme les los de composton algébrques, on peut assurer des transtons équvalentes, sous le même external stmul, entre les deux spécfcatons par la vérfcaton du homomorphsme. Défnton 4 Opératon de transformaton Sot un procédé centralsé P avec un ensemble de contextes CP et un ensemble de transtons T. Sot P l unon des procédés coopérants correspondants à P avec l ensemble de contextes CP et de transtons T. La foncton qu rele un contexte cp CP à un contexte cp CP est défne comme c-dessous : d cp (cp) = cp avec cp = {a start, a 1, a 2,..., a n } { a P n 1, n 2, n m } { a P out 1, out 2,..., out n } La défnton c-dessus exprme les relatons entre les éléments de deux algèbres. Par exemple deux actvtés nterconnectées de la spécfcaton centralsée a 1 et a 2 sont trouvées comme étant suves des actvtés de connexons venant après a 1 et avant a 2. La dépance de contrôle qu les lt est trouvée comme deux dépances de contrôle dans les procédés coopérants produts. Nous cherchons toujours à prouver que d cp (step(cp)) = step (d cp (cp)). Pour ce fare, nous défnssons les lemmes suvantes qu vont nous ader à prouver le théorème. Lemme 1 Sot P un procédé. Sot P un autre procédé qu dffère de P de telle sorte que seulement le composant condtonnel des transtons C est restrent comme sut. t = (source, cble, E[C]A) est changé en t = (source, target, E[C n source A). Sot t T, et, t T les transtons correspondantes à l nstant des procédés P et P, l asserton est vrae pour T et T : t T t T, >

193 Cette lemme assure que les transtons sont évaluées en même temps s les restrctons exprmées sur les données de condtons. Cela veut dre que quand les transtons sont évaluées, les transtons défnes avec les mêmes condtons sont également évaluées par les procédés coopérants. Mas dans ce cas, la queston essentelle est est-ce que une transton, même s une transton ntale, sera les mêmes effets sur l exécuton du procédé. Lemme 2 Sot P un procédé et P un procédé lmté par la contrante défne dans la lemme précédente. Sot A(t), Cond(t), D(t) les actvtés, les condtons et les données assocées à une transton t du procédé P et respectvement A(t ), Cond(t ), D (t) correspond à ceux du P. Les assertons suvantes sont vraes : A(t) = A(t ), Cond(t) = Cond(t ) et D(t) = D (t) pour t T et t T. Par rapport à cette dernère lemme, les transtons restrentes par les états des transtons antéreures ont les mêmes effets dans les deux procédés. Théorème 1 La transformaton d cp permettant de reler le contexte d un procédé au contexte des procédés coopérants correspondants consttue un homomorphsme. Cela s exprme au travers du fat que pour toute étape >= 0 et pour tout contexte de système cs du dagramme d état orgnel, l équaton d cp (step(cp )) = step (d cp (cp )) dot être satsfate, oú step est la foncton pour passer d un contexte à un autre et step est celle des procédés coopérants (tous les deux défns au travers des sémantques opératonnelles développées les défntons ntales). Preuve du théorème 1 A partr du fat que la foncton step est en réalté une foncton composte, la dérvaton formelle de l homomorphsme dot se référer au contexte cp. Il est alors nécessare de montrer que, pour toutes confguratons de contexte cp, et step(cp ) aboutt à la même confguraton que celle de d 1 cp (step (d cp (cp )). Consdérons un procédé p=(cp, T ), son ensemble d actvté A = {a 1,..., a n } et son ensemble de transtons T = {t 1,..., t m }. Sot cp = {e 1,..., e p } le contexte actuel. D abord nous allons transformer le procédé p := d cp (p) = (CP, T ) oú p := d cp (p), T := d cp (T ) T default et l ensemble des actvtés transformé A := {a start, a 1,...,a p,n a 1,...,n a n, out a 1,...,out a n }. La preuve est organsée en quatre étapes : Etape 1 : D abord nous la foncton step à cp, c est à dre exécuter step(cp ) : Etant donné cp, l ensemble des transtons d actvtées τ peut être calculé. Supposons que τ = {t k,...t 1 }. L actvaton de telles transtons permet de qutter certans états : t τ {source (t)} et d en rejondre d autres : t τ {target (t)}. Sans pour autant perdre la généralté, nous assumons que l ensemble des actvtés quttés est {a 1,..., a j 1 } et l ensemble des actvtés rejontes est {a p+1,..., a q }. D autre part, cp +1 = {e j,..., e p, e p+1,..., e q }. Pour le calcul du contexte cp +1, nous assumons que Conds + (t ), Conds (t ), D(t ), et A(t ), que sont respectvement l ensemble des condtons vraes, l ensemble des condtons fausses, l ensemble des données générés, et l ensemble des actvtés exécutées, ans que l ensemble de stmul externes {es +1 (x)} sont connus. Conformément aux lemmes 1 et 2, le nouveau contexte cp +1 est parfatement défn. Ans, step(cp ) = (cp +1 ). Etape 2 : Mantenant, nous allons applquer d cp à A et d cp à T : cp = d cp(cp )={a 1,..., a n, a 0, n a n, out a 1,..., out a n }. cp = d cp(cp ) = cp. 177

194 Annexe C. La preuve du théorème de l exacttude Etape 3 : Mantenant, nous allons applquer la foncton step à cp : D abord, nous calculons l ensemble des transtons d actvaton τ des procédés coopérants. Etant donné la lemme 2, τ = d cp (τ ). En prenant en compte le contexte, nous savons, d après les défnton 2 et 3, que chaque transton qu est un élément de n mporte quel d cp (t), t {t k,..., t 1 } at sot une actvté source qu est un élément de {n s s source }(t)}, sot une actvté cble qu est un élément de {n s s source }(t)} Par rapport au contexte défn, les assertons suvantes sont vraes : les changements du contexte peuvent avor leur rasons dans l exécuton des actvtés précédentes ou ben par un external stmul. En conséquence, la foncton de transformaton mplémentée par des algorthmes dans les chaptres précédents, une transton t est assocée à une autre transton t avec les mêmes condtons lbl. De ce résultat, on peut passer à l étape suvante. Etape 4 : Le derner pont porte sur l njectvté de l opératon de d cp qu est mentonnée dans les lemmes 1 et 2 pour montrer l assocaton de cp +1 à cp +1. cp +1 = d 1 cp (cp +1 ), d 1 cp (cp +1 ) = d 1 cp ({a 1, a 2, a n, a 0, out a 1, out a 1,.., out a 1,... n a 1, out a 2, out a n }) {a 1, a n,..., out a n}. De ces opératons, les étapes 4 et 1 présentent des résultats équvalents ce qu fat que d cp est un homomorphsme >

195 Bblographe [Ad and Etzon2004] Asaf Ad and Opher Etzon. Amt - the stuaton manager. VLDB J., 13(2) : , [Alonso et al.1996] Gustavo Alonso, Roger Günthör, Mohan Kamath, Dvyakant Agrawal, Amr El Abbad, and C. Mohan. Exotca/fmdc : A workflow management system for moble and dsconnected clents. Dstrbuted and Parallel Databases, 4(3) : , [Alonso et al.1997] Gustavo Alonso, Claus Hagen, Hans-Jörg Schek, and Markus Tresch. Dstrbuted processng over stand-alone systems and applcatons. In Proceedngs of 23rd Internatonal Conference on Very Large Data Bases, VLDB, pages , [Alonso et al.2004] Gustavo Alonso, Fabo Casat, Harum Kuno, and Vjay Machraju. Web Servces : Concepts, Archtectures and Applcatons. Sprnger-Verlag Berln hedelberg New York, [Andonoff et al.2005] Erc Andonoff, Lotf Bouzgua, and Chhab Hanach. Specfyng web workflow servces for fndng partners n the context of loose nter-organzatonal workflow. In Busness Process Management, pages , [Androutsells-Theotoks and Spnells2004] Stephanos Androutsells-Theotoks and Domds Spnells. A survey of peer-to-peer content dstrbuton technologes. ACM Comput. Surv., 36(4) : , [Aoyama et al.2002] Mko Aoyama, Sanjva Weerawarana, Hrosh Maruyama, Clemens A. Szypersk, Kevn J. Sullvan, and Doug Lea. Web servces engneerng : promses and challenges. In Proceedngs of the 22rd Internatonal Conference on Software Engneerng, ICSE, pages , [Atlur and Warner2005] Vjayalakshm Atlur and Jance Warner. Supportng condtonal delegaton n secure workflow management systems. In Proceedngs of the 10th ACM Symposum on Access Control Models and Technologes, SACMAT, pages 49 58, [Atlur et al.2001] Vjayalakshm Atlur, Soon Ae Chun, and Petro Mazzolen. A chnese wall securty model for decentralzed workflow systems. In ACM Conference on Computer and Communcatons Securty, pages 48 57, [Bares et al.2007] Lucano Bares, Andrea Maurno, and Stefano Modaffer. Dstrbuted bpel processes. In Proceedngs of the Nneteenth Internatonal Conference on Software Engneerng & Knowledge Engneerng, SEKE, pages , [Barros et al.2005] Alstar P. Barros, Marlon Dumas, and Arthur H. M. ter Hofstede. Servce nteracton patterns. In Wl M. P. van der Aalst, Boualem Benatallah, Fabo Casat, and Francsco Curbera, edtors, Proceedngs of 3rd Internatonal Conference, of Busness Process Management, BPM, volume 3649 of Lecture Notes n Computer Scence, pages Sprnger,

196 Bblographe [Benatallah et al.2002] Boualem Benatallah, Quan Z. Sheng, Anne H. H. Ngu, and Marlon Dumas. Declaratve composton and peer-to-peer provsonng of dynamc web servces. In Proceedngs of the 18th Internatonal Conference on Data Engneerng, ICDE, pages , [Benatallah et al.2006] Boualem Benatallah, Fabo Casat, and Farouk Touman. Representng, analysng and managng web servce protocols. Data Knowl. Eng., 58(3) : , [Berard et al.2005] Danela Berard, Dego Calvanese, Guseppe De Gacomo, Rchard Hull, and Massmo Mecella. Automatc composton of transton-based semantc web servces wth messagng. In Klemens Böhm, Chrstan S. Jensen, Laura M. Haas, Martn L. Kersten, Per- Åke Larson, and Beng Chn Oo, edtors, Proceedngs of the 31st Internatonal Conference on Very Large Data Bases, VLDB, pages ACM, [Bergholtz et al.2004] Mara Bergholtz, Prasad Jayaweera, Paul Johannesson, and Peta Wohed. A pattern and depency based approach to the desgn of process models. In Paolo Atzen, Wesley W. Chu, Hongjun Lu, Shugeng Zhou, and Tok Wang Lng, edtors, Proceedngs of the 23nd Internatonal Conference on Conceptual Modelng, ER, volume 3288 of Lecture Notes n Computer Scence, pages Sprnger, [Bertno et al.1999] Elsa Bertno, Elena Ferrar, and Vjayalakshm Atlur. The specfcaton and enforcement of authorzaton constrants n workflow management systems. ACM Trans. Inf. Syst. Secur., 2(1) :65 104, [Bertno et al.2004] Elsa Bertno, Elena Ferrar, and Anna Cnza Squccarn. Trust-x : A peerto-peer framework for trust establshment. IEEE Trans. Knowl. Data Eng., 16(7) : , [Bertno et al.2005] Elsa Bertno, Beng Chn Oo, Yanjang Yang, and Robert H. Deng. Prvacy and ownershp preservng of outsourced medcal data. In Proceedngs of the 21st Internatonal Conference on Data Engneerng, ICDE, pages IEEE Computer Socety, [Bertno2004] Elsa Bertno. Purpose based access control for prvacy protecton. In 20èmes Journées Bases de Données Avancées, BDA, page 243, [Betn-Can et al.2005] Aysu Betn-Can, Tevfk Bultan, and Xang Fu. Desgn for verfcaton for asynchronously communcatng web servces. In Allan Ells and Tatsuya Hagno, edtors, Proceedngs of the 14th nternatonal conference on World Wde Web, WWW, pages , [Bondy and Murty1976] J.A. Bondy and U.S.R. Murty. Graph Theory wth Applcatons. The Macmllan Press Ltd., [Box et al.2000] Don Box, Davd Ehnebuske, Gopal Kakvaya, Andrew Layman, Noah Melsohn., Henrk Frystyk Nelsen, Satsh Thatte, and Dave Wner. Smple object access protocol (soap) 1.1. W3c note, W3C, [BPMI.org2001] BPMI.org. Busness process modelng language (bpml). Workng draft 0.4, Busness Process Management Intatve, [Bultan et al.2006] Tevfk Bultan, Janwen Su, and Xang Fu. Analyzng conversatons of web servces. IEEE Internet Computng, 10(1) :18 25, [Ca et al.1996] Tng Ca, Peter A. Gloor, and Saurab Nog. Dartflow : A workflow management system on the web usng transportable agents. Techncal Report TR96-283, [Carlsson and Gustavsson2001] Bengt Carlsson and Rune Gustavsson. The rse and fall of napster - an evolutonary approach. In Actve Meda Technology, pages ,

197 [Chafle et al.2004] Grsh Chafle, Sunl Chandra, Vjay Mann, and Mangala Gowr Nanda. Decentralzed orchestraton of composte web servces. In WWW (Alternate Track Papers & Posters), pages , [Chafle et al.2005] Grsh Chafle, Sunl Chandra, Vjay Mann, and Mangala Gowr Nanda. Orchestratng composte web servces under data flow constrants. In IEEE Internatonal Conference on Web Servces, ICWS, pages IEEE Computer Socety, [Chen and Hsu2001] Qmng Chen and Mechun Hsu. Inter-enterprse collaboratve busness process management. In Proceedngs of the 17th Internatonal Conference on Data Engneerng, ICDE, pages , [Chnnc et al.2002] Roberto Chnnc, Martn Gudgn, Jean-Jacques Moreau, and Sanjva Weerawarana. Web servces descrpton language (wsdl) verson 1.2. Techncal report, W3C, [com1993] Com : Component object model technologes. Techncal report, Mcrosoft, [Coon2002] M. D. Coon. Peer-to-peer workflow management whte paper. Techncal report, http :// com/cmm/docs/p2p Workflow Whtepaper.do c. [cor] Common Object Request Broker Archtecture. http :// [Curbera et al.2002] Francsco Curbera, Matthew Duftler, Rana Khalaf, Wllam Nagy, Nrmal Mukh, and Sanjva Weerawarana. Ieee nternet computng : Spotlght - unravelng the web servces web : An ntroducton to soap, wsdl, and udd. IEEE Dstrbuted Systems Onlne, 3(4), [Curbera et al.2003] Francsco Curbera, Rana Khalaf, Frank Leymann, and Sanjva Weerawarana. Excepton handlng n the bpel4ws language. In Busness Process Management, pages , [Dahl et al.] O.-J. Dahl, Edsger W. Djkstra, and Charles Antony Rchard Hoare. Structured Programmng. Academc Press. [Daman et al.2007] Mara Lusa Daman, Elsa Bertno, Barbara Catana, and Paolo Perlasca. Geo-rbac : A spatally aware rbac. ACM Trans. Inf. Syst. Secur., 10(1), [Deng et al.2006] ShuGuang Deng, Yng L, Hajang Xa, Jan Wu, and Zhaohu Wu. Explorng the flexble workflow technology to automate servce composton. In Frst Asan Semantc Web Conference, ASWC, volume 4185 of Lecture Notes n Computer Scence, pages Sprnger, [Djkstra1959] E. W. Djkstra. A note on two problems n connexon wth graphs. Numersche Mathematk, 1 : , [Doyen2005] Gullaume Doyen. Supervson des réseaux et servces par à par. PhD thess, Unversté Henr Poncaré - Nancy I, [Draft] Udd Open Draft. Udd verson 2.0 ap specfcaton. [Dumas and Fauvet2006] Marlon Dumas and Mare-Chrstne Fauvet. Les servces web. Intergcel et Constructons d Applcatons Répartes, (chapter 4) :77 102, [Emerson1990] E. Allen Emerson. Temporal and modal logc. In Handbook of Theoretcal Computer Scence, Volume B : Formal Models and Sematcs (B), pages [emu2002] Emule project, http :// [Fakas and Karakostas2004] Georgos John Fakas and Bll Karakostas. A peer to peer (p2p) archtecture for dynamc workflow management. Informaton & Software Technology, 46(6) : ,

198 Bblographe [Fakas et al.2003] Georgos John Fakas, Bll Karakostas, and Stelos Chrstoph. A peer to peer (p2p) dynamc workflow management system based on web servces. In Proceedngs of the Internatonal Conference on Web Servces, ICWS, pages , [Fscher2007] Layna Fscher BPM & Workflow Handbook Methods, Concepts, Case Studes and Standards n Busness Process Management and Workflow. Future Strateges Inc., [Fu et al.2005] Xang Fu, Tevfk Bultan, and Janwen Su. Synchronzablty of conversatons among web servces. IEEE Trans. Software Eng., 31(12) : , [Gauron2006] Phlppe Gauron. Interconnexon et routage effcaces pour des procédures de recherche décentralsées dans les systèmes P2P. PhD thess, l Unversté Pars-Sud 11, [Godart1993] Claude Godart. Coo : A transacton model to support cooperatng software developers coordnaton. In Ian Sommervlle and Manfred Paul, edtors, Proceedngs of the 4th European Software Engneerng Conference, ESEC, volume 717 of Lecture Notes n Computer Scence, pages Sprnger, [Gokkoca et al.1997] Esn Gokkoca, Mehmet Altnel, Ibrahm Cngl, Nesme Tatbul, Pnar Koksal, and Asuman Dogac. Desgn and mplementaton of a dstrbuted workflow enactment servce. In Proceedngs of the Second IFCIS Internatonal Conference on Cooperatve Informaton Systems, CoopIS, pages 89 98, [Goldfard1990] C.-F. Goldfard. The SGML Handbook. Oxford Claron Press, [Gray and Reuter1993] Jm Gray and Andreas Reuter. Transacton Processng : Concepts and Technologes. Morgan Kaufmann Publshers, [Grnter et al.1999] Rebecca E. Grnter, James D. Herbsleb, and Dewayne E. Perry. The geography of coordnaton : dealng wth dstance n r&d work. In Proceedngs of the Internatonal Conference on Supportng Group Work, GROUP, pages , [Grundy and Hoskng1998] John C. Grundy and John G. Hoskng. Serpty : Integrated envronment support for process modellng, enactment and work coordnaton. Autom. Softw. Eng., 5(1) :27 60, [Guabtn and Charoy2004] Adnene Guabtn and Franços Charoy. Multple nstantaton n a dynamc workflow envronment. In Anne Persson and Jans Strna, edtors, Proceedngs of the 16th Internatonal Conference on Advanced Informaton Systems Engneerng, CASE, volume 3084 of Lecture Notes n Computer Scence, pages Sprnger, [Guabtn et al.2006] Adnene Guabtn, Franços Charoy, and Claude Godart. Usng solaton spheres for cooperatve processes correctness. In Proceedngs of the 10th Internatonal Conference on CSCW n Desgn, CSCWD, pages IEEE Computer Socety, [Hagen and Alonso2000] Claus Hagen and Gustavo Alonso. Excepton handlng n workflow management systems. IEEE Trans. Software Eng., 26(10) : , [Halevy et al.2006] Alon Y. Halevy, Anand Rajaraman, and Joann J. Ordlle. Ten-year best paper award talk sesson, data ntegraton : The teenage years. In Umeshwar Dayal, Kyu-Young Whang, Davd B. Lomet, Gustavo Alonso, Guy M. Lohman, Martn L. Kersten, Sang Kyun Cha, and Young-Kuk Km, edtors, Proceedngs of the 32nd Internatonal Conference on Very Large Data Bases, VLDB, pages ACM Press, [Harel and Naamad1996] Davd Harel and Amnon Naamad. The statemate semantcs of statecharts. ACM Trans. Softw. Eng. Methodol., 5(4) : , [Haugland et al.] Solveg Haugland, Mark Cade, and Anthony Orapallo. J2EE 1.4 : The Bg Pcture. Prentce Hall. 182

199 [jav] Java Dstrbuted Systems Home Page. http :// [Jøsang et al.2006] Audun Jøsang, Elzabeth Gray, and Mchael Knateder. Smplfcaton and analyss of transtve trust networks. Web Intellgence and Agent Systems, 4(2) : , [Josh et al.2005] James Josh, Elsa Bertno, and Arf Ghafoor. An analyss of expressveness and desgn ssues for the generalzed temporal role-based access control model. IEEE Trans. Depable Sec. Comput., 2(2) : , [Kahn1974] Glles Kahn. The semantcs of smple language for parallel programmng. In IFIP Congress, pages , [Kazhamakn and Pstore2006] Raman Kazhamakn and Marco Pstore. Choreography conformance analyss : Asynchronous communcatons and nformaton algnment. In Proceedngs of Thrd Internatonal Workshop on Web Servces and Formal Methods, WS-FM, volume 4184 of Lecture Notes n Computer Scence, pages Sprnger, [Kazhamakn et al.2006] Raman Kazhamakn, Marco Pstore, and Luca Santuar. Analyss of communcaton models n web servce compostons. In Les Carr, Davd De Roure, Arun Iyengar, Carole A. Goble, and Mchael Dahln, edtors, Proceedngs of the 15th nternatonal conference on World Wde Web, WWW, pages ACM, [Khalaf and Leymann2006] Rana Khalaf and Frank Leymann. busness processes usng bpel. In ICWS, pages , Role-based decomposton of [Kepuszewsk et al.2000] Bartek Kepuszewsk, Arthur H. M. ter Hofstede, and Chrstoph Bussler. On structured workflow modellng. In Advanced Informaton Systems Engneerng, 12th Internatonal Conference, CASE, volume 1789 of Lecture Notes n Computer Scence, pages Sprnger, [Kndler et al.2000] Ekkart Kndler, Axel Martens, and Wolfgang Resg. Inter-operablty of workflow applcatons : Local crtera for global soundness. In Wl M. P. van der Aalst, Jörg Desel, and Andreas Oberwes, edtors, Busness Process Management, volume 1806 of Lecture Notes n Computer Scence, pages Sprnger, [Kng1983] John Lesle Kng. Centralzed versus decentralzed computng : organzatonal consderatons and management optons. ACM Comput. Surv., 15(4) : , [Koutsonkola and Vakal2004] Vasslk A. Koutsonkola and Athena Vakal. Ldap : Framework, practces, and trs. IEEE Internet Computng, 8(5) :66 72, [Krzysztof Apt1997] Ernst-Rüdger Olderog Krzysztof Apt. Concurrent Programs. Sprnger-Verlag, Verfcaton of Sequental and [Leung and Reghbat1987] Hareton K. N. Leung and Hassan K. Reghbat. Comments on program slcng. IEEE Trans. Software Eng., 13(12) : , [Leymann and Roller2000] Frank Leymann and Deter Roller. Producton Workflow - Concepts and Technques. PTR Prentce Hall, [Lu and Kumar2005] Rong Lu and Akhl Kumar. An analyss and taxonomy of unstructured workflows. In Wl M. P. van der Aalst, Boualem Benatallah, Fabo Casat, and Francsco Curbera, edtors, Proceedngs of 3rd Internatonal Conference, of Busness Process Management, BPM, volume 3649 of Lecture Notes n Computer Scence, pages Sprnger, [Ly et al.2008] Lnh Thao Ly, Stefane Rnderle, and Peter Dadam. Integraton and verfcaton of semantc constrants n adaptve process management systems. Data Knowl. Eng., 64(1) :3 23,

200 Bblographe [Malk and Bouguettaya2007] Zak Malk and Athman Bouguettaya. Evaluatng rater credblty for reputaton assessment of web servces. In Proceedngs of 8th Internatonal Conference on Web Informaton Systems Engneerng, WISE, volume 4831 of Lecture Notes n Computer Scence, pages Sprnger, [Marcon et al.2006] Annapaola Marcon, Marco Pstore, and Paolo Traverso. Implct vs. explct data-flow requrements n web servce composton goals. In Servce-Orented Computng - ICSOC 2006, 4th Internatonal Conference, ICSOC, volume 4294 of Lecture Notes n Computer Scence, pages Sprnger, [Marjanovc2000] Olvera Marjanovc. Dynamc verfcaton of temporal constrants n producton workflows. In Australasan Database Conference, pages 74 81, [Mecella et al.2006] Massmo Mecella, Mourad Ouzzan, Federca Pac, and Elsa Bertno. Access control enforcement for conversaton-based web servces. In Les Carr, Davd De Roure, Arun Iyengar, Carole A. Goble, and Mchael Dahln, edtors, Proceedngs of the 15th nternatonal conference on World Wde Web, WWW, pages ACM, [Mlner1999] Robn Mlner. Communcatng and Moble Systems : the π-calculus. Cambrdge Unv. Press, [Muth et al.1998] Peter Muth, Drk Wodtke, Jeanne Weßenfels, Angelka Kotz Dttrch, and Gerhard Wekum. From centralzed workflow specfcaton to dstrbuted workflow executon. J. Intell. Inf. Syst., 10(2) : , [Myers and Lskov1997] Andrew C. Myers and Barbara Lskov. A decentralzed model for nformaton flow control. In SOSP 97 : Proceedngs of the sxteenth ACM symposum on Operatng systems prncples, pages , New York, NY, USA, ACM Press. [Nanda and Karnk2004] Mangala Gowr Nanda and Neeran M. Karnk. Synchronzaton analyss for decentralzng composte web servces. Int. J. Cooperatve Inf. Syst., 13(1) :91 119, [Nanda et al.2004] Mangala Gowr Nanda, Satsh Chandra, and Vvek Sarkar. Decentralzng executon of composte web servces. In Proceedngs of the 19th Annual ACM SIGPLAN Conference on Object-Orented Programmng, Systems, Languages, and Applcatons, OOPSLA, pages , [Nezhad et al.2006] Hamd R. Motahar Nezhad, Boualem Benatallah, Fabo Casat, and Farouk Touman. Web servces nteroperablty specfcatons. IEEE Computer, 39(5) :24 32, [OASIS2005] OASIS. Web Servces Busness Process Executon Language, verson 2.0 (retreved october 18, 2006), http ://docs.oass-open.org/wsbpel/2.0/wsbpel-specfcatondraft.html. [Omcn and Ossowsk2004] Andrea Omcn and Sascha Ossowsk. Coordnaton and collaboraton actvtes n cooperatve nformaton systems. Int. J. Cooperatve Inf. Syst., 13(1) :1 7, [Osterwel1987] Leon J. Osterwel. Software processes are software too. In Proceedngs of the 9th Internatonal Conference on Software Engneerng, ICSE, pages ACM Press, [Osterwel1997] Leon J. Osterwel. Software processes are software too, revsted : An nvted talk on the most nfluental paper of cse 9. In 19th Internatonal Conference on Software Engneerng, ICSE, pages ACM Press, [Ouyang et al.2006] Chun Ouyang, Marlon Dumas, Stephan Breutel, and Arthur H. M. ter Hofstede. Translatng standard process models to bpel. In Advanced Informaton Systems Engneerng, 18th Internatonal Conference, CASE, volume 4001 of Lecture Notes n Computer Scence, pages Sprnger,

201 [Park and Hwang2003] Joon S. Park and Junseok Hwang. Role-based access control for collaboratve enterprse n peer-to-peer computng envronments. In Proceedngs of the eghth ACM symposum on Access control models and technologes, pages 93 99, New York, NY, USA, ACM Press. [Paul et al.1997] Santanu Paul, Edwn Park, and Jarr K. Chaar. Ranman : A workflow system for the nternet. In USENIX Symposum on Internet Technologes and Systems, [Pautasso and Alonso2005] Cesare Pautasso and Gustavo Alonso. Flexble bndng for reusable composton of web servces. In Software Composton, volume 3628 of Lecture Notes n Computer Scence, pages Sprnger, [Pstore et al.2005] Marco Pstore, Annapaola Marcon, Pergorgo Bertol, and Paolo Traverso. Automated composton of web servces by plannng at the knowledge level. In Lesle Pack Kaelblng and Alessandro Saffott, edtors, Proceedngs of the Nneteenth Internatonal Jont Conference on Artfcal Intellgence, IJCAI, pages Professonal Book Center, [Port and Kaser1998] Danel Port and Gal E. Kaser. Collaboratve work : Collaboratve technologes for evolvng software systems. IEEE Internet Computng, 2(6) :79 83, [Rao et al.2006] Jngha Rao, Peep Küngas, and Mhhal Matskn. Composton of semantc web servces usng lnear logc theorem provng. Inf. Syst., 31(4-5) : , [Rechert and Dadam1998] Manfred Rechert and Peter Dadam. Adept flex -supportng dynamc changes of workflows wthout losng control. J. Intell. Inf. Syst., 10(2) :93 129, [Rechert et al.2004] Manfred Rechert, Stefane Rnderle, and Peter Dadam. On the modelng of correct servce flows wth bpel4ws. In Informatonssysteme m E-Busness und E-Government, Beträge des Workshops der GI-Fachgruppe, EMISA, volume 56 of LNI, pages GI, [Rnderle et al.2005] Stefane Rnderle, Barbara Weber, Manfred Rechert, and Werner Wld. Integratng process learnng and process evoluton - a semantcs based approach. In Busness Process Management, pages , [Rusnkewcz and Georgakopoulos1994] Marek Rusnkewcz and Dmtros Georgakopoulos. From transactons to transactonal workflows : Technology and applcatons. In Proceedngs of the Frst Internatonal Workshop on Advances n Databases and Informaton Systems, ADBIS, pages , [Rusnkewcz and Sheth1995] Marek Rusnkewcz and Amt P. Sheth. Specfcaton and executon of transactonal workflows. In Modern Database Systems, pages ACM Press and Addson-Wesley, [Sadq and Orlowska1999] Wasm Sadq and Mara E. Orlowska. Applyng graph reducton technques for dentfyng structural conflcts n process models. In Proceedngs of the Advanced Informaton Systems Engneerng, 11th InternatonalConference, CASE, volume 1626 of Lecture Notes n Computer Scence, pages Sprnger, [Sadq and Orlowska2000a] Wasm Sadq and Mara E. Orlowska. Analyzng process models usng graph reducton technques. Inf. Syst., 25(2) : , [Sadq and Orlowska2000b] Wasm Sadq and Mara E. Orlowska. On busness process model transformatons. In ER, pages , [Sadq et al.2006] Wasm Sadq, Shaza W. Sadq, and Karsten Schulz. Model drven dstrbuton of collaboratve busness processes. In Proceedngs of the IEEE Internatonal Conference on Servces Computng, SCC, pages IEEE Computer Socety,

202 Bblographe [Schollmeer2001] Rüdger Schollmeer. A defnton of peer-to-peer networkng for the classfcaton of peer-to-peer archtectures and applcatons. In 1st Internatonal Conference on Peer-to-Peer Computng, pages IEEE Computer Socety, [Schuldt et al.1999] Heko Schuldt, Gustavo Alonso, and Hans-Jörg Schek. Concurrency control and recovery n transactonal process management. In Proceedngs of the Eghteenth ACM SIGACT-SIGMOD-SIGART Symposum on Prncples of Database Systems, PODS, pages ACM Press, [Schuler et al.2004] Chrstoph Schuler, Roger Weber, Heko Schuldt, and Hans-Jörg Schek. Scalable peer-to-peer process management - the osrs approach. In Proceedngs of the IEEE Internatonal Conference on Web Servces, ICWS, pages 26 34, [SDSC1999] SDSC. San dego super computng center, Matrx. [Sheth and Kochut1997] Amt Sheth and K.J Kochut. Workflow applcatons to research aga : Scalable and dynamc work coordnaton and collaboraton systems. In NATO Advanced Study Insttute on Workflow Management Systems and Interoperablty, Istanbul, Türkye,, [Sheth1991] Amt P. Sheth. Federated database systems for managng dstrbuted, heterogeneous, and autonomous databases. In VLDB, page 489, [Srvastava and Velegraks2007] Dvesh Srvastava and Yanns Velegraks. Intensonal assocatons between data and metadata. In Chee Yong Chan, Beng Chn Oo, and Aoyng Zhou, edtors, Proceedngs of the ACM SIGMOD Internatonal Conference on Management of Data SIGMOD Conference, pages ACM, [Strcker et al.1995] Thomas Strcker, James M. Stchnoth, Davd R. O Hallaron, Susan Hnrchs, and Thomas R. Gross. Decouplng synchronzaton and data transfer n message passng systems of parallel computers. In Internatonal Conference on Supercomputng, pages 1 10, [Than et al.2005] Douglas Than, Todd Tannenbaum, and Mron Lvny. Dstrbuted computng n practce : the condor experence. Concurrency - Practce and Experence, 17(2-4) : , [Thatte2001] Satsh Thatte. Xlang - web servces for busness process desgn. Intal publc draft, Mcrosoft Corporaton, [van der Aalst and Berens2001] Wl M. P. van der Aalst and P. J. S. Berens. Beyond workflow management : product-drven case handlng. In Proceedngs of ACM Internatonal Conference on Supportng Group Work, GROUP, pages 42 51, [van der Aalst and Weske2001] Wl M. P. van der Aalst and Mathas Weske. The p2p approach to nterorganzatonal workflows. In Proceedngs 13th Internatonal Conference of Advanced Informaton Systems Engneerng, CASE, volume 2068 of Lecture Notes n Computer Scence, pages Sprnger, [van der Aalst et al.2000] Wl M. P. van der Aalst, Alstar P. Barros, Arthur H. M. ter Hofstede, and Bartek Kepuszewsk. Advanced workflow patterns. In Proceedngs of the 7 th Internatonal Cooperatve Informaton Systems Conference, CoopIS, volume 1901 of Lecture Notes n Computer Scence, pages Sprnger, [van der Aalst1998] Wl M. P. van der Aalst. The applcaton of petr nets to workflow management. Journal of Crcuts, Systems, and Computers, 8(1) :21 66,

203 [van der Aalst1999] Wl M. P. van der Aalst. Interorganzatonal workflows : An approach based on message sequence charts and petr nets. Systems Analyss - Modellng - Smulaton, 3(34) : , [van der Aalst2005] W.M.P. van der Aalst. Process mnng n cscw systems. In Proceedngs of the 9th IEEE Internatonal Conference on Computer Supported Cooperatve Work n Desgn, CSCWD, pages 1 8. Coventry Unversty/IEEE Computer Socety Press, [W3C] W3C. Extensble markup language (xml). [W3C2005] W3C. Web Servces Choreography Descrpton Language Verson 1.0 (Canddate Recommaton), [Weerawarana et al.2005] Sanjva Weerawarana, Francsco Curbera, Frank Leymann, Tony Storey, and Dan Ferguson. Web Servces Platform Archtecture. Prentce Hall, [WfMC1996] WfMC. Workflow standard - nteroperablty abstract specfcaton verson 1.0. Document number wfmc-tc-1012, Workflow Management Coalton, [Wodtke and Wekum1997] Drk Wodtke and Gerhard Wekum. A formal foundaton for dstrbuted workflow executon based on state charts. In Foto N. Afrat and Phokon G. Kolats, edtors, Proceedngs of the 6th Internatonal Conference on Database Theory - ICDT 97, pages , Delph, Greece, [Wodtke et al.1997] Drk Wodtke, Jeanne Weßenfels, Gerhard Wekum, Angelka Kotz Dttrch, and Peter Muth. The mentor workbench for enterprse-wde workflow management. In SIGMOD Conference, pages , [Wohed et al.2003] Peta Wohed, Wl M. P. van der Aalst, Marlon Dumas, and Arthur H. M. ter Hofstede. Analyss of web servces composton languages : The case of bpel4ws. In Il-Yeol Song, Stephen W. Lddle, Tok Wang Lng, and Peter Scheuermann, edtors, Proceedngs of the 22nd Internatonal Conference on Conceptual Modelng, ER, volume 2813 of Lecture Notes n Computer Scence, pages Sprnger, [Wombacher2006] Andreas Wombacher. Decentralzed consstency checkng n crossorganzatonalworkflows. In ghth IEEE Internatonal Conference on E-Commerce Technology (CEC 2006) / Thrd IEEE Internatonal Conference on Enterprse Computng, E-Commerce and E-Servces (EEE 2006), page 7. IEEE Computer Socety, [wsf] Techncal report. [Yang and Lu2006] Zahan Yang and Chengfe Lu. Implementng a flexble compensaton mechansm for busness processes n web servce envronment. volume 0, pages , Los Alamtos, CA, USA, IEEE Computer Socety. [Yldz and Godart2007a] Ustun Yldz and Claude Godart. Centralzed versus decentralzed conversaton-based orchestratons. In 9th IEEE Internatonal Conference on E-Commerce Technology (CEC 2007) / 4th IEEE Internatonal Conference on Enterprse Computng, E- Commerce and E-Servces (EEE 2007), pages , [Yldz and Godart2007b] Ustun Yldz and Claude Godart. Dynamc decentralzed servce orchestratons. In Bruno Encarnacao Joaqum Flpe, José Cordero and Vtor Pedrosa, edtors, Proceedngs of the 3 th Internatonal Conference on Web Informaton Systems and Technologes, WEBIST, pages 36 45, Span, INSTICC Press. (Best Student Paper Award). [Yldz and Godart2007c] Ustun Yldz and Claude Godart. Enhancng secured servce nteroperablty wth decentralzed orchestraton. In Proceedngs of the 23 th Internatonal Conference on Data Engneerng Workshops, ICDE Workshops, pages IEEE Computer Socety,

204 Bblographe [Yldz and Godart2007d] Ustun Yldz and Claude Godart. Informaton flow control wth decentralzed servce compostons. In Proceedngs of the 5 th IEEE Internatonal Conference on Web Servces, ICWS, pages IEEE Computer Socety Press, [Yldz and Godart2007e] Ustun Yldz and Claude Godart. Synchronzaton solutons for decentralzed servce orchestratons. In Stefana Galza, edtor, Proceedngs of the Second IEEE Internatonal Conference on Internet and Web Applcatons and Servces, ICIW, pages 39 46, Maurtus, IEEE Computer Socety Press. [Yldz and Godart2007f] Ustun Yldz and Claude Godart. Towards decentralzed servce orchestratons. In Proceedngs of the 27 th ACM Symposum on Appled Computng, SAC, pages ACM Press, [Yldz2008] Ustun Yldz. Contrôle du flux d nformaton dans une composton de servces. In Actes du XXVIème Congrès Informatque des organsatons et systèmes d nformaton et de décson, INFORSID. Lavoser - Hermès, [Yu et al.2004] Weha Yu, Yan Wang, and Calton Pu. A dynamc two-phase commt protocol for self-adaptng servces. In IEEE Internatonal Conference on Servces Computng, SCC, pages 7 15, [Zhao et al.2005] Xaohu Zhao, Chengfe Lu, and Yun Yang. An organsatonal perspectve on collaboratve busness processes. In Proceedngs of the 3rd Internatonal Conference Busness Process Management, pages 17 31, [Özsu and Valdurez1999] Tamer Özsu and Patrck Valdurez. Prncples of Dstrbuted Database Systems. Prentce-Hall, Inc.,

205 Résumé Les travaux de recherche de cette thèse portent sur la modélsaton et la geston des procédés méters orentés servces. Le traval s ntéresse aux procédés d un pont de vue de geston décentralsée où les servces composés peuvent établr des nteractons de parà-par. Dans un premer temps, nous présentons une méthode qu permet de dérver des procédés coopérants à partr d une spécfcaton centralsée. Il s agt des algorthmes qu analysent un procédé centralsé pour le tradure en procédés coopérants, en transformant le flux de contrôle et le flux de données du procédé d orgne en nteractons équvalentes de type par-à-par. Un des apports de la décentralsaton, qu répond à une nouvelle exgence des procédés orentés vers les servces, est l établssement des nteractons de par-à-par qu respectent le flux d nformaton des servces composés. La deuxème parte du traval est la proposton d un langage permettant d exprmer des poltques de flux d nformaton. Par la sute, nous étudons l ntégraton des poltques du flux d nformaton dans les procédés coopérants. Le chox dun servce entrant dans une composton peut être effectué dynamquement, au moment de l exécuton du procédé, de sorte que l ensemble des servces composés n est pas connu à pror. Une compréhenson de la stratége de chox dynamque des servces et leur ntégraton dans le cadre des contrbutons proposées dans son ensemble est pour cela une étape centrale. Pour ce fare, une méthodologe qu automatse le processus de déploement dynamque des procédés coopérants est proposée. Le traval présente une archtecture logcelle qu valde les concepts proposés. Abstract Ths thess studes decentralzed management of busness processes n the context of servce orented archtectures. We present a generc approach that enables decentralzed executons wth cooperatng processes by mplemetng the centralzed semantc wth P2P nteractons. Precsely, we present our method that derves the latter. We focus on the sophstcated control/data flow and conversatonal aspects that run counter to nave ntuton, most of whch, we explan usng deeper analyss of the algorthms and data structures that we employed. In the second part of the manuscrt, we focus on nformaton flow control that conssts of plannng the nteractons of composed servces n order to satsfy dfferent securty restrctons concernng the propagaton of nformaton n a composton. We examne the questons of what the nformaton flow s and how t can be modeled and computed n servce-orented busness processes. We present the desgn and mplementaton of a decentralzed workflow management soluton for the control of nformaton flow. The derved process fragments are deployed on composed servces and they enable them to establsh P2P nteractons wth each other wth respect to nformaton flow polces. The last contrbuton takes on the challenge of mplementng dynamc and decentralzed process deployment followng the same approach. Our conceptual contrbutons are mplemented wth state-of-art technologes.

Montrer encore