La nouvelle g�n�ration des technologies d?information et de communication a contribu� � l?�mergence de nouveaux paradigmes de management tels que l?entreprise virtuelle (Mecella et al., 2001) (Mecella et al., 2002) (Colombo et al. 2003) : diff�rentes organisations s?associent pour offrir des produits et des services plus complexes, � forte valeur ajout�e, facilement accessibles par Internet. Ce nouveau paradigme trouve son application dans de nombreux domaines de l?industrie et du commerce.

Le support � la mise en ?uvre de ces nouveaux paradigmes est apport� par des Syst�mes d?Information Coop�ratifs. Ces syst�mes se fondent sur une approche de coordination des processus entre organisations (inter-organisations) qui est obtenue en partageant, composant et coordonnant des services publi�s sur l?Internet. Ces services sont des e-Services ou Web Services (Mecella et al., 2002) ��export�s� des diff�rentes organisations et permettant aux utilisateurs et aux applications d?acc�der et d?ex�cuter des t�ches offertes par les applications du back office. Un syst�me d?information coop�ratif comporte diff�rentes applications distribu�es qui int�grent les e-Services offerts par diff�rentes organisations.

Le paradigme est s�duisant. N�anmoins, la pierre angulaire de cette nouvelle technologie est la possibilit� d?agencer entre eux des services pour fournir des services plus complexes � forte valeur ajout�e.

Cet agencement ou composition pose deux probl�mes diff�rents. Le premier est de pouvoir �lucider les services composites et d?identifier les web services qui vont participer � la composition. Ce probl�me est guid� par les besoins des organisations partenaires et les exigences que ces besoins imposent au syst�me d?information coop�ratif. Le second probl�me est relatif � la synchronisation et la coordination des services composites comme le souligne Mecella et al. (2002). Dans le premier cas, on parle de composition et d?orchestration dans le second.

Des travaux de recherche actuels ou r�cents traitent le deuxi�me probl�me. Par exemple, Casati et Shan (2001) appellent m�ta e-service, un e-service qui coordonne d?autres e-services est appel� un et le consid�rent comme un e-service composite pouvant �tre invoqu� par des demandeurs de services. Fauvet et al. (2001) mod�lisent un e-service par des diagrammes d?�tats o� chaque �tat est associ� � un service et � l?ensemble des param�tres n�cessaires � son ex�cution. Pour Mecella et al. (2002), l?orchestration des e-services est mod�lis�e par des r�seaux de Petri. Finalement, d?apr�s Shegalov (2001), la coordination des e-services est assur�e par un moteur d?ex�cution qui interpr�te les mod�les de processus d�finis par des diagrammes d?�tats.

Le premier probl�me a re�u moins d?attention de la part des chercheurs. Toutefois, Aiello et al. (2002) proposent une approche de composition bas�e sur un ensemble de contraintes � satisfaire. McIlraith et Son (2001), le probl�me de la composition est r�solu en repr�sentant la composition par un arbre dont les n?uds repr�sentent un e-service programm� dans un langage sp�cifique CONGOLOG. Quartel et al. (2004) utilisent une approche bas�e sur le langage ISDL pour mod�liser la composition des services � un haut niveau d?abstraction. Enfin, Berardi et al. (2004) proposent une mani�re de composer automatiquement les services en se basant sur un ensemble d?automates exprim�s � l?aide de formules �crites avec le langage PDL_gm.

Malgr� ces efforts, une approche m�thodologique pour d�couvrir et �lucider les besoins des organisations partenaires, pour identifier, distribuer et orchestrer les services fait d�faut. Ainsi, l?objectif de cet article est de contribuer � combler ce manque.

Nous proposons dans cet article de d�finir une approche m�thodologique qui permet d?expliciter le besoin de diff�rentes organisations d?un service composite � forte valeur ajout�e et de mod�liser le processus coop�ratif supportant ce service. Le mod�le des besoins, orient� but et appel� mod�le de la Carte, sert de support � l?identification, la distribution et l?orchestration des services, facilitant ainsi le passage � une application distribu�e ex�cutable. Dans cet article, l?approche propos�e est illustr�e par E-Pension, une application coop�rative de E-gouvernement inspir�e des travaux de Mecella et al. (2001) et de Batini (2001). L?article est organis� comme suit. La section 2 pr�sente un survol de l?approche. La section 3 est consacr�e � la mod�lisation du processus coop�ratif que nous illustrons par le cas E-Pension. Nous montrons en section 4, comment le mod�le du processus coop�ratif, la carte E-Pension, sert � �l?identification des services composites, � leur mod�lisation et � leur d�veloppement. Nous illustrons ce dernier point en utilisant Microsoft BizTalk Server 2004. La section 5 traite l?orchestration des services composites formant le processus coop�ratif. Nous concluons en section 6.

L?approche propos�e met l?accent sur l?�lucidation et l?expression des besoins impliqu�s par la coop�ration inter organisations au sein de l?entreprise virtuelle. La d�marche est dirig�e par l?identification des buts � atteindre collectivement et des strat�gies ou mani�res de le faire. Pour assurer la plus grande flexibilit� possible au processus coop�ratif, l?approche aide les acteurs � identifier de multiples fa�ons d?atteindre l?objectif global du processus. Elle s?appuie pour cela sur un m�ta mod�le de repr�sentation de processus, le m�ta mod�le de la Carte qui est multid�marches, c?est-�-dire qu?il permet de repr�senter dans un m�me mod�le de processus plusieurs chemins pour aller du point de d�part au point de terminaison. Le processus est construit dynamiquement par navigation dans l?ensemble des chemins possibles et en tenant compte des situations rencontr�es.

Le mod�le du processus coop�ratif inter organisations sert de support � la recherche de la solution technique par l?identification des services � offrir et la d�couverte des web services qui les composent. Ils peuvent �tre construits � partir des syst�mes d?information existants dans les diff�rentes organisations et de la mod�lisation fine de la composition de services.

La d�marche est organis�e en cinq �tapes�:

• mod�liser le processus coop�ratif,

• identifier les services composites,

• mod�liser les services composites et identifier les web services,

• d�velopper les services composites,

• orchestrer les services composites.

La premi�re �tape vise � comprendre et sp�cifier les besoins des organisations partenaires et les exigences que ces besoins imposent au syst�me d?information coop�ratif. Pour ce faire, nous utilisons le m�ta mod�le de la Carte qui permet de repr�senter le processus coop�ratif en termes de buts � atteindre et de strat�gies pour les atteindre. La carte est le moyen de repr�sentation des besoins de la communaut� des parties prenantes et sert de support de l?�valuation du bien fond� du processus coop�ratif. Elle est pr�sent�e sous la forme d?un graphe orient� o� les intentions sont �symbolis�es par les n?uds et les strat�gies �par les arcs. La seconde �tape du processus m�thodologique vise � identifier les services composites � partir des besoins du m�tier exprim�s dans une carte. Cette �tape s?appuie sur le couplage direct que l?on peut �tablir entre les besoins des utilisateurs mod�lis�s dans la carte et les exigences de service qu?ils imposent. La troisi�me �tape sert � mod�liser les services composites. L?approche pr�conise une approche centr�e sur les interactions entre acteurs et s?appuie sur des motifs g�n�riques de coop�ration. Les motifs simplifient la t�che de mod�lisation et �vitent les erreurs puisque la pertinence et la correction des motifs sont �prouv�es. La mod�lisation fine des interactions permet d?identifier les fonctionnalit�s r�cup�rables dans les syst�mes d?information existants (legacy) que l?on sugg�re de transformer en web services. La quatri�me �tape a pour objectif de d�velopper les services composites. Dans le cadre de cet article, on illustre cette �tape par le d�veloppement des services composites � l?aide de Microsoft BizTalk Server 2004. La derni�re �tape montre les m�canismes d?orchestration des services composites que nous projetons de mettre en place.

La d�marche est illustr�e par un cas de E-gouvernement, le cas E-Pension. L?objectif est de mettre en place un processus coop�ratif facilitant les t�ches du citoyen qui fait la demande d?une pension pour handicap.

Dans cette section, on montre comment les besoins de travail coop�ratif sont mod�lis�s dans un graphe labell� et dirig�, compos� d?intentions et de strat�gies. Ce graphe est appel� Carte. On pr�sente le mod�le de la Carte et on illustre son usage dans le cas E-Pension.

Le mod�le de la Carte est d�crit dans les d�tails par Rolland et al. (2000). On se limite � en introduire les concepts-cl�s dans cette section.

Le mod�le de la Carte (Map) est un syst�me de repr�sentation intentionnelle. Il repose sur un ordonnancement d�claratif et flexible d?intentions et de strat�gies. La figure 1 pr�sente le m�ta mod�le de la Carte, ses concepts cl�s et leurs relations en utilisant la notation UML. La figure 2 montre un exemple de carte.

Le mod�le de la Carte (figure 1) montre qu?une carte est compos�e de sections. Une section est une agr�gation de deux types d?intention, une intention source et une intention cible, et d?une strat�gie. Chaque section correspond � une strat�gie qui peut �tre utilis�e pour r�aliser une intention cible, une fois que l?intention source a �t� atteinte. La carte est repr�sent�e par un graphe orient� et �tiquet�. Les intentions sont les n?uds et les strat�gies en sont les arcs. La nature orient�e de la carte traduit le flux de l?intention source � l?intention cible via la strat�gie. Une section est ainsi repr�sent�e par deux n?uds reli�s par une fl�che. Dans l?exemple de la figure 2, la carte comporte 5 intentions, 7 strat�gies et 7 sections.

Une intention est un objectif que l?on peut atteindre par l?ex�cution d?un ou plusieurs processus. Nous ajoutons que chaque carte poss�de deux buts particuliers, D�marrer et Arr�ter, pour commencer et terminer l?ex�cution de la carte. Une strat�gie est une approche, une mani�re ou un moyen pour r�aliser une intention. Une section est un triplet compos� d?un but source, d?un but cible et d?une strat�gie. Une section exprime la r�alisation du but cible en utilisant la strat�gie une fois que le but source a �t� r�alis�.

Comme le montre la figure 2, les sections sont reli�es par des relations de deux types�:�multi-segment et multi-chemin. La topologie est appel�e multi-segment lorsqu?il �est possible, dans une carte, de r�aliser un but cible � partir d?un but source en utilisant plusieurs mani�res. Chacune de ces mani�res est exprim�e comme une section dans la carte. La topologie est multi-chemin dans le cas o� un but est r�alisable, dans une carte, en utilisant diff�rentes combinaisons de sections. En d?autres termes, un but donn� peut �tre r�alis� en suivant plusieurs chemins dans le graphe.

Cet exemple, d�sign� E-Pension, est extrait de (Batini, 2001) et repr�sente une version simplifi�e du processus qui a comme but global �Aider les personnes handicap�es � obtenir une pension�.

Dans l?�tat actuel, un citoyen pr�sentant un handicap peut demander une pension du gouvernement. Afin de commencer le processus, la personne a besoin d?une attestation de domiciliation fournie par la mairie de son arrondissement puis elle remplit un formulaire de demande de pension. Ces documents sont pr�sent�s ensuite au Local Health Authority (LHA, entit� m�dicale) qui, apr�s avoir n�goci� un rendez-vous avec le citoyen, l?examine et pr�pare un rapport formulant une pr�-d�cision. Le rapport est ensuite envoy� � la pr�fecture qui prend la d�cision finale. Le citoyen doit entre-temps communiquer � la pr�fecture sa demande de pension et re�oit un accus� de r�ception. Dans le cas o� la demande de pension est accept�e, la pr�fecture pr�pare tous les documents n�cessaires � l?�tablissement du dossier de paiement de la pension et les transmet ensuite au citoyen qui, � son tour, peut alors percevoir sa pension chaque mois.

La description pr�c�dente a �t� abr�g�e mais elle montre cependant que le processus est long et compliqu�, surtout pour des personnes handicap�es. On observe qu?un temps consid�rable est d�pens� � transmettre des documents d?une administration � une autre. En outre, il incombe au citoyen de suivre son dossier.

La solution que nous proposons dans cet article est celle d?une application coop�rative dans le contexte de l?organisation virtuelle form�e du LHA, de la pr�fecture et de la mairie, afin de permettre la r�alisation du but ��fournir une aide aux personnes handicap�es�� dans des conditions plus ais�es. Nous appelons cette organisation virtuelle E-Pension.

La Carte de la figure 3 montre le processus coop�ratif de l?organisation virtuelle E-Pension. Au sein du processus coop�ratif, les organisations impliqu�es, le LHA, la pr�fecture et la Mairie, coop�rent les unes avec les autres afin de �fournir une aide aux personnes handicap�es�.

La carte E-Pension identifie l?ensemble des intentions qui doivent ou peuvent �tre accomplies afin d?aider les personnes handicap�es � obtenir une pension et l?ensemble des strat�gies qui d�finissent la mani�re d?accomplir ces intentions. Comme le montre la figure 3, le processus s?organise autour de deux intentions principales�:

• �Formuler la demande pour formuler la requ�te de demande d?une pension,

• Statuer sur la demande afin de prendre une d�cision relative � la demande de pension en question en choisissant la mani�re de la r�aliser.

La Carte comporte plusieurs strat�gies pour atteindre ces deux intentions. Il existe ainsi, plusieurs mani�res de r�aliser l?intention Formuler une demande�: (1) Par authentification du citoyen, �(2) Par capture d?informations, (3) Par attestation de domiciliation et (4) Par attribution d?un rendez-vous m�dical. L?organisation virtuelle E-Pension voudrait s�curiser l?acc�s aux donn�es personnelles des citoyens. La strat�gie Par authentification du citoyen a �t� introduite dans cette perspective. Les informations personnelles constituant la requ�te du citoyen sont captur�es en utilisant la strat�gie Par capture d?informations. Afin de s?assurer que l?ensemble des citoyens demandeurs de pension sont bien des habitants de la ville, la strat�gie Par attestation de domiciliation est mise en place avec l?id�e de faciliter l?obtention de l?attestation par le citoyen. L?examen assur� par le LHA reste n�cessaire et la strat�gie Par attribution d?un rendez-vous m�dical a �t� introduite pour permettre au citoyen d?obtenir un rendez-vous ais�ment.

La carte E-Pension montre aussi qu?il existe plusieurs strat�gies permettant de satisfaire la seconde intention Statuer sur la demande. En effet, il est possible de la r�aliser � partir de l?intention source Formuler une demande en utilisant deux segments possibles�: Passer un examen m�dical et Passer un examen m�dical certifi�. Ces strat�gies offrent le choix au citoyen�: il/elle peut choisir de passer l?examen m�dical soit au LHA soit chez un m�decin asserment� par l?organisation E-Pension. Le contr�le du processus ainsi que la prise de la d�cision finale relative � une demande sp�cifique sont des t�ches d�l�gu�es � la pr�fecture�; le contr�le du processus comprend l?envoi des messages de relance si n�cessaire, dans le cas o� le dossier d?un citoyen est incomplet. Ces t�ches sont r�alis�es via la strat�gie Par contr�le de la pr�fecture qui garantit que le monitoring du processus n?est plus assur� par le citoyen mais bien par l?organisation virtuelle. La pr�-d�cision est prise par le LHA via la strat�gie Par pr�-d�cision du LHA mais la d�cision finale incombe � la pr�fecture par application de la strat�gie Par d�cision de la pr�fecture. Enfin, d?apr�s la carte E-Pension il existe un multi-segment entre l?intention source Statuer sur la demande et l?intention cible Arr�ter qui repose sur trois strat�gies. La strat�gie Par transfert au service de traitement des pensions �arr�te le processus dans le cas o� une d�cision positive est prise par la pr�fecture et dans ce cas le dossier du citoyen est transf�r� au service payeur. La strat�gie Par rejet de la demande est appliqu�e lorsque la d�cision est n�gative. A chaque instant, le citoyen peut arr�ter le processus en retirant sa demande de pension en appelant la strat�gie Par d�sistement du citoyen.

Dans cette section, nous pr�sentons la d�marche qui permet d?identifier les services composites, de les mod�liser pour ensuite les d�velopper. Nous illustrons avec le cas E-Pension, les trois �tapes � savoir�:

• identifier les services composites,

• mod�liser les services composites,

• d�velopper les services composites.

Le d�veloppement des services est illustr� en utilisant la plate-forme de d�veloppement Microsoft BizTalk 2004.

La carte E-Pension est construite dans une perspective m�tier qui met l?accent sur le processus coop�ratif de l?organisation virtuelle afin de r�aliser le but global �Aider les personnes handicap�es � obtenir une pension�. Toutefois, l?une des caract�ristiques du mod�le de la Carte est l?exploitation des connaissances du m�tier pour d�finir les exigences du syst�me. En effet, la vue m�tier et la vue syst�me ne s?opposent pas mais au contraire doivent �tre align�es pour que le syst�me d?information soit en concordance avec les besoins de ses futurs utilisateurs. Le mod�le de la Carte a �t� pens� pour qu?une carte puisse �tre une expression des besoins du monde organisationnel et en m�me temps, d�finisse les exigences de service du syst�me d?information. Une carte a donc une double facette�: elle est une expression du m�tier, de ses buts et des strat�gies pour les atteindre mais elle d�termine en cons�quence, les services du syst�me qui sont aptes � supporter la r�alisation de ces buts et strat�gies. Afin d?�tablir un couplage direct entre les fonctionnalit�s exig�es du syst�me et les besoins du m�tier, nous proposons d?associer � chaque section de la carte un service du syst�me.

En appliquant ce couplage aux sections de la carte E-Pension, nous identifions douze services logiciels. Chacun de ces services correspond � une section de la carte E-Pension. Nous les pr�sentons bri�vement dans le en se limitant aux sections qui contribuent � la r�alisation de l?intention Formuler une demande de la carte E-Pension.

Cette �tape de la d�marche m�thodologique a pour objectif de mod�liser les services composites formant l?application coop�rative de fa�on �:

• identifier les E-services r�utilisables, c?est � dire identifier les parties des syst�mes d?information de chaque organisation pouvant �tre encapsul�es dans des web services et r�utilis�es dans l?application coop�rative en cours de d�veloppement�;

• d�crire l?appel aux e-services dans les interactions coop�ratives qui les requi�rent.

Pour ce faire, les �tapes pr�conis�es sont (1) le choix du mode de coop�ration, (2) l?application du motif de coop�ration et (3) la construction du diagramme de s�quences afin de mod�liser les services composites comme des int�ractions coop�ratives appelant les web services r�utilisables. On d�veloppe chacune des �tapes en les illustrant dans le cas E-Pension.

Plusieurs modes de coop�ration entre organisations ont �t� identifi�s par Kolp et al. (2001) et �Do et al. (2003). Par exemple, on identifie 5 modes d�crits dans 5 motifs. Nous pensons qu?il est important que les organisations qui coop�rent au sein d?une entreprise virtuelle se concertent sur le mode de coop�ration � mettre en place et l?explicitent. Ce choix influence la mani�re dont les interactions coop�ratives se d�rouleront et par cons�quent, influence la mani�re de mod�liser les interactions.

Notre proposition est d?utiliser les motifs de Kolp et al. (2001) � la fois pour aider les organisations � d�terminer leur mode de coop�ration mais aussi pour faciliter la mod�lisation des interactions coop�ratives. Nous avons retenu les motifs coop�ratif et centralis� pour la coop�ration au sein d?une entreprise virtuelle.

- Le motif coop�ratif�propose une coordination distribu�e, fond�e sur la communication d?�gal � �gal (peer-to-peer, P2P) entre les parties prenantes. Ce mode est recommand� pour la coop�ration entre organisations dont les relations sont �tablies avec un bon niveau de confiance. Les interactions directes entre participants sont autoris�es mais un acteur particulier, le Coordonnateur, a pour r�le de g�rer l?ensemble des donn�es partag�es entre les participants. Il joue le r�le d?interm�diaire puisque toutes les donn�es qui transitent entre les parties prenantes passent par lui.

- Le motif centralis�organise la coordination de mani�re centralis�e et fait appel � un acteur central, le Coordonnateur. Ce mode d?interaction est recommand� lorsque les organisations participantes ont un faible niveau de confiance mutuelle. Les interactions directes entre les parties prenantes ne sont pas autoris�es�; toutes se d�roulent via le Coordonnateur. Ce dernier a pour r�le, en outre, de g�rer les donn�es partag�es entre les parties prenantes.

Une fois que le mode de coop�ration a �t� d�termin�, notre proposition est d?utiliser le motif d?interaction coop�rative correspondant pour aider � la mod�lisation de l?interaction.

Les motifs de Kolp et al. (2001) sont des graphes i* de d�pendances entre acteurs (Yu, 1995). Leur int�r�t est de mettre clairement en �vidence les diff�rents types d?acteurs associ�s � un mode de coop�ration donn� et leurs d�pendances �nonc�es sous forme de buts. La d�pendance exprime qu?un acteur A d�pend d?un acteur B pour atteindre un but G. Par exemple, la figure 4 pr�sente le motif d?interaction centralis� qui met en �vidence trois acteurs et leurs d�pendances :

• le demandeur initie la demande de service,

• le coordonnateur� est un acteur syst�me qui contr�le tous les �changes entre partenaires et g�re l?ensemble des donn�es partag�es�;

• le fournisseur�correspond au propri�taire du service.

Le demandeur d�pend du coordonnateur pour la demande de service ainsi que pour la demande d?un ensemble de donn�es partag�es. Le coordonnateur de son cot� d�pend du fournisseur pour fournir le service demand� par le demandeur. Il d�pend aussi du demandeur pour la d�cision d?acceptation ou de refus du service demand�. Enfin, le fournisseur d�pend du coordonnateur pour la r�alisation, l?acceptation ou le refus du service fourni ainsi que pour la demande d?un ensemble de donn�es partag�es.

La figure 5 montre l?application du motif centralis� au service composite �allocation de rendez-vous m�dicaux� (section S4 de la carte E-Pension).

La figure 5 met en �vidence les trois acteurs du motif centralis� appliqu� au service S4. Pour le service �allocation de rendez-vous m�dicaux�, ces acteurs sont�:

• le citoyen� c'est-�-dire le demandeur du service,

• E-Pension� qui correspond au coordonnateur.

• LHA� qui repr�sente le fournisseur.

Le citoyen d�pend de E-Pension pour la demande d?un rendez-vous m�dical. L?E-Pension de son cot� d�pend du LHA pour lui fournir le service demand� par le Citoyen. Il d�pend aussi du citoyen pour la d�cision d?acceptation ou de refus du rendez-vous m�dical demand�. Enfin, le LHA d�pend de E-Pension pour l?acceptation ou le refus du rendez-vous choisi.

Le motif de coop�ration appliqu� � chaque section de la carte joue un double r�le : il permet d?identifier les acteurs et il donne une premi�re �bauche de leurs interactions par un graphe i* (figure 5). Il est n�cessaire de d�tailler la mod�lisation de chacune des interactions coop�ratives sous-jacentes � un service (section de la carte), en particulier pour faire ressortir les fonctionnalit�s des syst�mes d?information de chacune des organisations participantes susceptibles de devenir des web services.

Nous avons choisi de le faire en optant pour une approche guid�e par les interactions pour identifier dans une communication qui demande quoi. Le quoi sert � �lucider les web services candidats. Le qui sert � identifier l?appel au web service. La mod�lisation des interactions s?appuie sur une repr�sentation graphique de la conversation entre les acteurs. Ces sch�mas caract�risent chaque interaction par les diff�rents acteurs participants, les comp�tences m�tiers n�cessaires au d�roulement de la conversation, la nature des messages �chang�s et enfin le d�roulement temporel de l?interaction. Nous avons utilis� le diagramme de s�quences du standard UML (Booch et al., 1998) (Rumbaugh et al., 1998) pour mod�liser les interactions entre les acteurs identifi�s.

La figure 6 pr�sente le diagramme de s�quences du service composite S4 (section S4 de la carte E-Pension). Ce diagramme respecte le motif d?interaction choisi (motif centralis�) ainsi que les acteurs mis en jeu.

En figure 6, les fl�ches pleines repr�sentent les web services candidats alors que les fl�ches en pointill� indiquent les appels aux web services. Parmi les trois web services candidats, le premier est exprim� de la ligne 3 � la ligne 5 et correspond � la demande d?un rendez-vous m�dical. Il commence par l?envoi d?une demande de rendez-vous m�dical par le citoyen, ��Demande d?un rendez-vous��. La fin de ce web service est marqu�e par l?envoi d?une liste de rendez-vous m�dicaux ��listes de rendez-vous�� au citoyen pour le choix �ventuel d?un d?un rendez-vous. Le second web service (ligne 9 � �ligne 11) est ex�cut� apr�s qu?un rendez-vous m�dical soit choisi par le citoyen. Finalement, le troisi�me web service est similaire au pr�c�dant mais n?est ex�cut� que dans le cas o� aucun rendez-vous ne serait appropri� au citoyen (ligne 14 � 16 du diagramme de s�quences).

Chacun de ces web services est appel� dans le service S4 et le diagramme de s�quences est un moyen qui aide � identifier ces appels. En effet, � titre d?exemple, les lignes 1, 7 et 13 correspondent respectivement aux appels des web services introduits. Chaque appel initie une interaction dont la fin est marqu�e par une r�ponse � cet appel et incorpore l?ex�cution du web service correspondant. Certes, l?appel fait par le citoyen en ligne 1 initie une interaction qui se termine au niveau de la ligne 6 quand le web service d?allocation de rendez-vous m�dicaux est ex�cut�.

Les r�gles ci-dessous permettent d?identifier les web services candidats et leur appel respectif�:

• soit S le syst�me coop�ratif � d�velopper, A un acteur du processus coop�ratif et U un utilisateur final de l?application�;

• soit I_coop une interaction entre S et A�; I_ext une interaction entre U et S�; I_ext est une interaction entre le syst�me et un utilisateur final�; I_coop fournit le support coop�ratif � I_ext�;

• chaque I_coop incorpor�e dans un I_ext peut contenir une fonctionnalit� r�utilisable qui peut �tre encapsul�e dans un web service�; I_ext peut contenir l?appel � ce web service.

Le tableau 2 liste l?ensemble des web services de la carte E-Pension identifi�s suivant l?approche propos�e.

A ce stade de la d�marche, nous avons identifi� les services composites formant l?application coop�rative et nous les avons mod�lis� par des diagrammes de s�quences. Le but de cette section est d?illustrer leur impl�mentation.

Notre choix technique consiste � utiliser BizTalk Server 2004 (Roxburgh, 2001) comme plate-forme technique. BizTalk simplifie la t�che des d�veloppeurs et assure une pr�sentation standardis�e des donn�es et des processus. La figure 7 pr�sente l?architecture globale de la solution et la cin�matique compl�te du processus de r�alisation du service composite d?allocation de rendez-vous m�dicaux. Il est d�riv� du diagramme de s�quences de la figure 6.

BizTalk utilise le standard BPEL, Business Process Execution Language, qui est un langage de sp�cification des processus m�tiers (Andrews et al. 2003). Le passage de la figure 7 au code en BPEL est relativement ais�. La figure 8 donne l?exemple de la programmation du processus d?allocation du rendez-vous sp�cifi� en BPEL.

Dans ce qui suit, une explication br�ve du processus est pr�sent�e. Le processus d?allocation de rendez-vous AppointmentAllocation met en interaction deux partenaires qui sont d�finis de la ligne 2 � la ligne 11�: la ligne 3 � 6 introduit le citoyen Citizen et la ligne 7 � 10 introduit le partenaire LHA.La d�finition des partenaires inclus la sp�cification des web services utilis�s par le processus. Les messages �chang�s dans le processus sont encapsul�s dans des containers (ligne 12 � 19). Dans notre exemple, nous avons deux messages�: AppointmentRequestMessage encapsul� dans le container AppointmentRequest et AppointmentListMessage encapsul� dans le container AppointmentList. AppointmentRequestMessage est envoy� par le citoyen (ligne 25) en invoquant l?op�ration AppointmentRequest (ligne 27). Ce message est encapsul� dans le container AppointmentRequest (ligne 28). Le BizTalk Server (E-Pension) se charge ensuite de passer le container AppointmentRequest au LHA (ligne 31) en utilisant l?op�ration AppointmentRequest (ligne 33). Afin de d�terminer l?ordre d?ex�cution des services, le processus AppointmentAllocation structure l?appel aux op�rations suivant un flux d?op�rations flow (ligne 20).

L?objectif de cette section est double. Le premier vise � r�partir les services composites (et leurs web services incorpor�s) identifi�s � la section 4.1 entre les acteurs identifi�s au niveau de la section 4.2. Le deuxi�me objectif vise � orchestrer ces services composites distribu�s.

Nous supposons que les services contr�l�s par un m�me acteur (demandeur ou fournisseur) sont group�s dans un seul service composite formant ce qu?on appelle un d-service (pour service distribu�). Le coordonnateur n?est pas pris en consid�ration car il ne repr�sente pas une organisation fournissant des services mais un acteur syst�me.

Dans le cas de l?application E-Pension, nous avons quatre d-services�: le citoyen, la mairie, le LHA et enfin la pr�fecture. Suivant le lien �tabli � la section 4.1, nous pouvons identifier la composition de services pour chacun des quatre d-services de l?application E-Pension. Le montre ce lien.

Chaque d-service est mod�lis� sous la forme d?une carte issue de la carte globale et d�sign�e d-carte (pour carte distribu�e). La figure 9 montre les quatre d-cartes mod�lisant les quatre d-services.

La mod�lisation des d-services avec des d-cartes n?est pas seulement une simple agr�gation de services mais c?est une structure complexe correspondant aux topologies multi-segments et multi-chemins (section 3). Elle permet d?une part, de combiner les diff�rents services via la topologie multi-segments et d?autre part, de combiner les sections de la carte suivant plusieurs chemins alternatifs via la topologie multi-chemins. De plus, cette structure permet au moment de l?ex�cution de (1) s�lectionner l?alternative la plus appropri�e dans le multi-segment, i.e. de s�lectionner dynamiquement le service qui correspond le mieux � la situation courante et, (2) composer dynamiquement les services en constituant ��� la vol�e�� le chemin de l?intention D�marrer � l?intention Arr�ter. La description d�clarative des services composites via les buts du mod�le de la carte permet d?ex�cuter les services en s�lectionnant et composant dynamiquement des services.

A ce niveau de la m�thode, nous avons identifi� les d-services formant la base de l?application E-Pension. Nous avons mod�lis� chaque d-service par une d-carte. Dans cette section, nous consid�rons l?orchestration de ces services composites distribu�s. L?orchestration permet de d�finir l?encha�nement de services selon un canevas pr�d�fini et de les ex�cuter � travers un sch�ma d?orchestration. Ces sch�mas d�crivent souvent l?interaction entre services en identifiant les messages �chang�s et les s�quences d?invocation de service (Peltz, 2003).

Suivant notre approche guid�e par les buts, l?orchestration des services composites est d�finie via un ensemble de d�pendances entre les d-cartes.

L?orchestration est le support d?ex�cution des services et notre approche consiste � introduire un m�canisme d?orchestration dirig� par les cartes. Chaque d-service est sous le contr�le d?un m�canisme d?ex�cution d�sign� par moteur de d-carte. Chaque moteur fonctionne suivant un ensemble de r�gles d?ex�cution communes et il contr�le la s�lection et l?ex�cution des services composites en interpr�tant la d-carte. Notre architecture est donc une architecture dirig�e par les mod�les o� la carte forme le c?ur du contr�le de l?ex�cution du service. Les fonctionnalit�s de ce moteur d?ex�cution sont r�sum�s comme suit.

• Il d�termine les instances des sections candidates c?est � dire les instances des sections qui doivent �tre ex�cut�es � la prochaine �tape. Pour ce faire, le moteur s?appuie sur la trace des sections d�j� ex�cut�es, les contraintes de pr�c�dence entre les sections d?une carte et les d�pendances entre les d-cartes,

• Il s�lectionne les instances des sections � ex�cuter et d�clenche son ex�cution par l?invocation du service. Pour cela, le moteur se fonde sur le couplage direct entre les sections de la carte et les services composites. Ce couplage est exprim� formellement dans les sp�cifications de la Carte.

• Il garde la trace des instances des sections d�j� ex�cut�es.

Chaque moteur d?une d-carte fonctionne suivant sa propre d-carte. Toutefois, pour assurer l?orchestration globale suivant un mode distribu�, il est n�cessaire d?�changer des informations d?un moteur � un autre. Ces informations sont fond�es sur les liens de d�pendances entre les d-cartes qui garantissent l?orchestration des d-services composant l?application.

Le concept de d�pendance est une relation entre deux sections indiquant que la r�alisation d?une intention cible d?une section donn�e d�pend de la r�alisation de l?intention cible d?une section d?une autre d-carte. On distingue deux cat�gories de d�pendances :

• la d�pendance d?exclusion� exprime qu?une instance d?une section B ne peut �tre ex�cut�e si une instance de la section A a d�j� �t� ex�cut�e�; l?utilisation de cette d�pendance implique que l?ex�cution de l?instance d?une section A exclut l?ex�cution d?une instance d?une section B�;

• la d�pendance de pr�c�dence �signifie qu?une instance d?une section B ne peut pas �tre ex�cut�e que si une instance d?une section A a d�j� �t� ex�cut�e�; l?utilisation de cette d�pendance implique que l?ex�cution d?une instance d?une section B peut commencer une fois que l?instance d?une section A a d�j� �t� ex�cut�e.

La figure 10 montre les d�pendances d?orchestration entre les d-cartes de l?application E-Pension. Les fl�ches en pointill� indiquent les d�pendances de pr�c�dence entre deux sections alors que les fl�ches pleines repr�sentent les d�pendances d?exclusion. Chacune d?entre elles est une d�pendance �tiquet�e avec les valeurs des param�tres � transmettre d?une section � une autre.

Consid�rons la d�pendance de pr�c�dence entre la section S6 de la d-carte formalisant le d-service du citoyen et la section S7 de la d-carte du d-service du LHA�; �le LHA ne peut prendre sa pr�-d�cision (section S7) que s?il a d�j� re�u les r�sultats de l?examen physique du citoyen (section S6). De la m�me mani�re, la pr�fecture ne peut prendre sa d�cision (section S8) que dans le cas o� elle aurait d�j� obtenu la pr�-d�cision du LHA (section S7).

La figure 10 montre aussi un exemple d?une d�pendance d?exclusion entre la section S10 et S11 de la d-carte. En effet, la pr�fecture ne peut accepter la demande de pension d?un citoyen (section S10) dans le cas o� la d�cision de rejet serait d�j� prise (section S11). De la m�me mani�re, la pr�fecture ne peut pas prendre une d�cision positive et transf�rer le dossier du citoyen au service payeur (section S10) dans le cas o� le citoyen se r�tracterait et annulerait sa demande de pension (section S12).

La composition des services est certainement un des concepts des plus prometteurs. Il est important pour les entreprises qui veulent cr�er des partenariats avec d?autres organisations. La composition est le cha�non manquant entre les perspectives d?interop�rabilit� et de standards ouverts. Toutefois, ce concept est difficile � mettre en ?uvre. La composition peut offrir des avantages comp�titifs aux organisations en leur donnant la possibilit� de d�velopper des services � valeur ajout�e en assemblant les services dont ils disposent d�j�. Afin de fournir un support m�thodologique pour le d�veloppement de ces services, nous avons propos� dans cet article, une approche guid�e par les buts qui aide �(1) capturer les besoins de l?application coop�rative en termes de buts � atteindre et de strat�gies pour les atteindre, (2) d�river les services de chaque organisation, (3) �lucider les web services incorpor�s dans ces services, (4) orchestrer les services composant l?application et, (5) ex�cuter l?orchestration d?une mani�re guid�e par le mod�le.

Parmi les caract�ristiques de cette approche, notons qu?elle met l?accent sur la notion de buts pour capturer les besoins et qu?elle ex�cute l?orchestration des web services satisfaisant ces besoins. La capture des besoins vise � comprendre et sp�cifier les besoins des organisations partenaires et les exigences que ces besoins imposent au syst�me d?information coop�ratif. Par contre, l?ex�cution de l?orchestration des web services est une solution plus complexe dans le sens o� les web services sont identifi�s de mani�re intentionnelle en leur associant un ensemble de buts qu?ils doivent r�aliser et leur ex�cution est guid�e dans ce cas par un mod�le de buts. Ceci est r�alis� par le couplage direct entre l?expression des besoins (section de la carte) et le service r�alisant cette section. Dans ce sens, la composition est exprim�e et ex�cut�e au niveau intentionnel. Cela aide d?une part, � minimiser consid�rablement l?�cart conceptuel entre les services et le mod�le de buts o� les services ont �t� d�riv�s et d?autre part, � faciliter la propagation des besoins de changement dans le sens o� les changements sont propag�s du processus m�tier actuel vers les changements du syst�me c?est � dire lors de l?ex�cution des services.

Nos travaux futurs consistent tout d?abord � utiliser le lien d?affinement pour mod�liser chaque section d?une carte par une carte, les besoins �tant donc exprim�s par une hi�rarchie de cartes. Nous envisageons �galement d?am�liorer les �tapes constituant l?approche propos�e et d?introduire d?autres types de d�pendances afin d?assurer l?orchestration des services. Enfin, �le quatri�me objectif est de concevoir et de r�aliser un prototype d?ex�cution distribu� de processus coop�ratif fond� sur un moteur d?orchestration des services.